knigge for software architects

Knigge for Software ArchitectsBy Peter Hruschka and Gernot Starke

TYPO3 Camp Rhein-Ruhr 2015

Gernot Schulmeister | [email protected] 14.11.2015 Seite 2wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com

Knigge for Software Architects

Gernot Schulmeister… Lives in Mönchengladbach… Developes websites with TYPO3 since Version 3.7

(2005)… Works for wfp:2 … Has a migration background and comes from

Southeast-Europe (Austria)… Likes operative CMS evaluations

Contact• facebook.com/gernot.schulmeister• twitter.com/mistakanista1

MotivationOverview

Anti PatternsPatterns

Schedule

Motivation

Overview

Anti Patterns

Dictator - Misjudger



Dictator• Smart alecks, patronizer, justification objectors are

often ignored, boycotted and undermined → desaster• Architator: dictator with power for architectural and

technical decisions• Dictators make decisions without giving reasons and

ignoring objections• Balance between clear decisions and endless

discussions is necessary • Monarch – friendly, constructive dictators terminate

endless, unproductive discussion by clear, founded decisions



Misjudger• Misjudger deliver clear numbers for costs, response

times and availibilities → putative safety • Estimations are lead to absurdity by reality• Responsible architects disclose uncertainties and risks

in estimations• Misjudge causes stress for developers• Misjudge costs money (estimations based on few,

unclear requirements is needed tomorrow morning)



Techniques for better estimations• First count then estimate (Use cases, features,

change requests)• Historical data from old similar projects• Expert estimations of people who know the field• Divide and conquer (decomposition)• More independent estimations• Estimate quality features (performance, transactions)

→ prototyping• Estimate products → decision making

Perfectionist – too much of the good



Perfectionist• Perfectionism is very expensive (Pareto 80:20 principle)• Causes overtime and bad conscious for employees• Perfection trap source code: stop refactoring after

business targets have been reached• Perfection trap organization: will fail because

organization is based on humans• Perfection trap decision: suboptimal decision today is

better then best decision in six months• Instead clean pragmatism: suboptimal solutions when

necessary

Ignorant – codehero – ivory tower



Ignorant• Not invented here syndrome• Avoids reuse, makes everything on its own and can

everything• Prefer to make mistakes himself than to learn of

mistakes of others• Cause: school punishes copying• Instead: learn from others, neighbor projects,

architecture & design patterns, reference architectures• Ivory tower: loose relation to reality, programs

features which no one needs



Code hero• Last minute code and features• Tries to solve all problems with new code• Avoids communication but code is written in teams• Code is important, but describes facts not reasons• You see a lot of tree but not the wood• Source code is not enough as input for humans• Important decisions are not written in the code• Other documentation than code is needed

Notation warrior – process preacher



Notation warrior – process preacher• Shape is more important than content• Regulations, rules and standards are law• Stick to the process for any price• Comprehensibility has priority• Pragmatism – no sloppiness• Results are more important than check off steps• Architects should know their tasks (make requirements

comprehensible, structure and technical decisions, communicate to stakeholders, get feedback, evaluate risks and solutions)



Other anti patterns• Toolistan → a fool with a tool• Dirty slob → writes dirty code

Patterns

Simplifying goblin



Simple is good – target simple solution• Easier to understand, modify and extend• Less bugs, risks and effort, cheaper • Simplify complicated technology• Direct paths are better than paths through many layers

and frameworks • Warn of complex business cases and golden faucets• Appreciate simplicity → simplifying minute• But: simplify too much → falsify

Proactive – rear view mirror



Proactive• Behavior similar to successful business man• Opposite of reactive, don´t wait until someone asks• Look for improvements in requirements engineering,

test, build & risk management • Clarify assumptions and preconditions – the technical

solution should be based on facts• Contact stakeholder actively to learn and get feedback • Show enthusiasm for your system or project• Define the tasks yourself and get things done



Looking in the rear view window• Evaluation methods for their decisions to measure the

quality objectives• PDCA plan, do, check, act, iteratively• Check the status of the architecture, technical

concepts, structures, models, documentation and implementation based on the artefacts

• Look for bugs, vulnerabilities, risks and omissions• Process improvements: correct assumptions, reached

targets, problems with boundary conditions or requirements, missing technical know how

Decision maker



Decision maker• Decisions are the basis of every design• Clarify the question or the problem• Which conditions and requirements are valid• Which assumptions are taken and verified, known risks • Evaluate alternatives• Make decision and justify and document them• Early, last responsible moment, timeboxed decisions• Courageous decision but no foolhardiness



Important architectural decisions• Cost now or later a lot of money• Many stakeholders are concerned• Affects the system core• Affects important quality issues • Long term validity and hard to replace• Many consequences and side effects within the system• Consequences for interfaces or neighbor systems• Go beyond the experience horizon

Cleaner



Code smells• Inconprehensible, awkward code, injured conventions,

abuse or wrong use of the programming language• No test automation → legacy code• Code that causes pain at run time by bad performance

or high resource consumption• Code that hinder or prevents changes• Code that differs from the rest by using other concepts,

paradigmas, frameworks or languages• Risky code who might cause problem in future• Code that simply looks bad



Find the dirt and clean• Measure the rate of pollution and the run time• Clean parts who are often used first• Afferent coupling → interactions and responsibility of a

code block: cleaning most important• Identify the code to change and define test cases• Solve dependencies and write test cases• Change the code and refactor• Knowledge of static code analysis tools (SonarQube)

important for code cleaner



Other patterns• Multi viewers → many views on the system• Structured lazyness → templates for recurring tasks• Multilinguist → speak the language of all stakeholders• Juggler → solve conflicts between stakeholders• Lector → write simple documentations• The noble knight → defend quality issues• Changes as normal case → reimplement is no option• Investigator → looks for code crimes• Exterminator → looks for bugs and fixes them



Conclusion• Very good book which gives a lot of new insights• Also useful for software developers• The authors stick to their documentation principles and

write short and entertaining

knigge for software architects

Internet