�ݺ�ߣ

Knigge for
Software Architects
By Peter Hruschka and Gernot Starke
TYPO3 Camp Rhein-Ruhr 2015

Gernot Schulmeister | gernot.schulmeister@wfp2.com 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

Motivation
Overview
Anti Patterns
Patterns
Schedule

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 �C 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 �C 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 �C codehero �C 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 �C process preacher

Notation warrior �C 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 �C 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

Simple is good �C 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 �C 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 �C 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
? 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

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

More Related Content

Knigge for software architects