The document describes different design orientations that software developers can have: simple, powerful, abstract, pragmatic, robust, concrete, idealistic, and technological. It tells a story of two developers, Bob and Sally, who struggle with their different orientations of powerful and simple, respectively, in designing a software project. Their project fails due to a lack of robustness. Two other developers, Jack and Sam, who have abstract and pragmatic orientations, are able to help stabilize the project by refactoring the architecture and focusing on quick implementation. The document concludes by explaining each of the design orientations and how understanding them can help teams work together more effectively.

1. Entscheidungsmöglichkeiten beim Design von Software
DESIGN TYPES
Christian Rehn, Matthias Wittum

2. Vorstellung
Matthias Wittum:
 In der Software-Entwicklung seit 2002
 In der 1&1 seit 2007
 Tätig als Software-Entwickler/Architekt
 Seit 2012 Head of Source Center
 Erreichbar unter: matthias.wittum@1und1.de
2 17.11.2014 1&1 Internet AG
Christian Rehn:
 Programmiert seit 2001
 In der 1&1 seit 2013
 Tätig als Software Engineer
 Erreichbar unter: christian.rehn@1und1.de
 Blog: www.christian-rehn.de/
 Design-Prinzipien: www.principles-wiki.net

3. Let‘s start with an demonstrative story
Hi,
I am John.
3 17.11.2014
1&1 Internet AG
I work as a
manager for a
company that
produces textiles
like shirts.

4. The vision and the team
For the company
we will accelerate our business
if we sell our products online
(without any merchants in between)
4 17.11.2014
1&1 Internet AG
Bob and Sally
you will start
Implementing
The vision
Hi,
I am Sally.
Hi,
I am Bob.
Currently involved in
too many other projects
Hi,
I am Jack. Hi,
I am Sam.

5. Split up tasks
I will take over
the frontend part
5 17.11.2014
1&1 Internet AG
…
I will take over
the backend part
I found a very
interesting GUI
framework where
I can separate layout
from functionality
XSD
XML
I will use an event
driven architecture
where I can decouple
all elements from
each other
Service A
a queue
a rule
handler
Service B
Both have a Technologic orientation means:
 using new, modern and more productive technologies
 evolve with technology for being more competitive
 broaden their personal horizon
 etc.

6. After a while…
Bob and Sally:
please give me a
brief overview how
you proceeded so far
6 17.11.2014
1&1 Internet AG
XSD Service A
XML
Service B
Service C
I found a perfect
solution for the GUI.
We can separate
functionality from design.
Give me some money
to delegate the layout part.
I implemtent the functionality.
I started with an EDA
that is totally flexible.
We can add new
events/services on
demand e.g. engage
Logistics, BI, etc.
Sounds very
technical
but great.
Please prepare
a Demo!

7. Before the first demo
Bob I do not understand
your interface. Too much
xml, xsd, generic methods, etc.
How can I use it or can you
make it easier to use?
7 17.11.2014
1&1 Internet AG
It is like it is. Read my manual
or just use the xsd – it is self
describing.
Currently there is no example
I was working on a test
framework for my EDA.
But we have to
deliver a demo.
I don‘t see it!
Don‘t be
so clumsy
You are a
Bubble Bob
And you:
Sally2Simple
Sally is oriented in Simple that means:
 keeping it simple for better understandability
 omit unnecessary things (lower risk; less bugs)
 reduce complexity by splitting it up
 prefer explicit solutions instead of implicit knowledge
 etc.
Bob is oriented in Powerful that means:
 powerful and generalized solutions
 Flexibility and Extensibility by foresighted design
 configurable solutions instead of frequent code changes
 mastering complexity
 etc.
Without a
conclusion they
decide to
demonstrate their
own parts.

8. During the first demo
Bob and Sally:
Let‘s see
8 17.11.2014
1&1 Internet AG
Here is the brand
new shop!
Awesome
Service A
Test data
Generator
XML
Impressive
What about
an order about
1000 Shirts
with a discount
of 10% using
a credit card?
With the test
data generator
I can simulate
everything

9. The disaster
9 17.11.2014
1&1 Internet AG
Oh – NO!!!
Damn it!
Both are Technologic oriented but not Robust which means:
 protect applications against risks and potential bugs
 use standards for an obvious structure
 avoid magic and complexity
 use proven solutions which stand the test of time
 etc.

10. How to proceed?
Sam and Jack:
Can you support?
10 17.11.2014
1&1 Internet AG
yep
sure
Jack with his
architectural
background
will be in charge
of the structure

11. Fixing the unfixable
11 17.11.2014
1&1 Internet AG
XSD Service A
XML
Service B
Service C
Facade
How does it all
play together?
Let‘s use a simple
API for the GUI
And remove the
complex stuff
calling services
directly (maybe
using it later on)
Now I will
help Sally
with the
stability
Jack is Abstract oriented which means:
 think in concepts and abstractions
 focus on the big picture and interaction of components
 know about the consequences of a change
 focus on real world models
 etc.

12. Getting things done
12 17.11.2014
1&1 Internet AG
XSD Service A
XML
Service B
Service C
Bob: we go together
through all services
to see
what is available,
what is working
and bring it on quickly
ok
?
?
?
Sam is Pragmatic oriented which means:
 fulfill requirements asap
 use only things that guarantee a value
 omit unnecessary things
 bring others down to earth
 etc.

13. Celebrating success
13 17.11.2014
1&1 Internet AG
Congratulations!
We did it.
Thank you all…

14. Let‘s sum up
 Sally and Bob are both technologic oriented
but are too contrary regarding powerful and
simple software design.
 Both are also not robust oriented which lead
to an instable system, here.
 There was no agreement about a common
architecture because Bob is concrete oriented
and Sally could not negotiate with Bob after
their heated debate. Both are also idealistic
which complicated any agreements
 Jack could support based on his orientation to
abstract (this was maybe supported by getting
the technical lead from John)
 Sam could bring down Bob to earth and
supported by finding the quick wins in his
pragmatic manner.
Simple
Abstract
Idealistic
Technologic
Powerful
Concrete
Idealistic
Technologic
14 17.11.2014
1&1 Internet AG
Powerful
Abstract
Pragmatic
Robustness
Simple
Abstract
Pragmatic
Robustness

15. Why is the example not representative?
 First of all it is a fictive story.
 In reality it will be different (circumstances, type combinations,
etc.)
 Not all problems can be solved in the same way or in this case
by a manager 
What we wanted to show/our motivation:
 Several orientations can motivate a developer to make his
design decisions.
 There are many ways to build good or bad solutions. Get to
know and understand these ways.
 There are often one or two dimensions which overweight.
15 17.11.2014
1&1 Internet AG

16. A guide through design type dimensions
Simple means:
 keeping it simple for better understandability
 omit unnecessary things (lower risk; less bugs)
 reduce complexity by splitting it up
 prefer explicit solutions instead of implicit knowledge
 etc.
16 17.11.2014
1&1 Internet AG
Powerful means:
 powerful and generalized solutions
 Flexibility and Extensibility by foresighted design
 configurable solutions instead of frequent code changes
 mastering complexity
 etc.
Abstract means:
 think in concepts and abstractions
 focus on the big picture and interaction of components
 know about the consequences of a change
 focus on real world models
 etc.
Pragmatic means:
 fulfill requirements asap
 use only things that guarantee a value
 omit unnecessary things
 bring others down to earth
 etc.
Robust means:
 protect applications against risks and potential bugs
 use standards for an obvious structure
 avoid magic and complexity
 use proven solutions which stand the test of time
Concrete means:
 think and act in code
 transferring ideas into components immediately
 optimizing algortihms for better performance
 understanding systems by reading the code
 etc.
Idealistic means:
 make things right – not only 80%
 consider all aspects not only functional ones
 everything has its right place
 do not missuse existing concepts
 etc.
Technologic means:
 using new, modern and more productive technologies
 evolve with technology for being more competitive
 broaden their personal horizon
 etc.
Follower of each dimension use their particular design principles.
Have a look on www.principles-wiki.net to get an overall overview.

17. Try it by yourself > www.design-types.net
17 17.11.2014
1&1 Internet AG
Simple
Abstract
Idealistic
Technologic
Simple
Abstract
Pragmatic
Robust

18. What‘s in for me?
From a developer‘s perspective:
 Understand the motivation for particular design decisions
of your colleagues.
 Get to know yourself – strenghts and weaknesses.
 More precise and less exhausting communication about
design decisions.
From a managers perspective:
 Identify which dimension is missing in my team.
 Build up new teams according to the team mission.
 Put the right ones together for e.g. a project or to learn
from each other.
18 17.11.2014
1&1 Internet AG

19. Source Center
„Die Richtigen an die richtige Stelle im Unternehmen bringen.“
Wie funktioniert das Source Center?
 Einarbeitung (Technologien, Prozesse, Kultur)
 Teameinsatz (~6 Monate produktiver Einsatz)
 Fach-/Technologische Spezifika kennenlernen
 Soziales Netzwerk aufbauen
 Standort übergreifender Einsatz möglich (finanziert AG)
 Wechsel in dauerhafte Position jederzeit möglich (Gegenseitigkeit)
19 17.11.2014 1&1 Internet AG

20. ZEIT FÜR FRAGEN…
…UND FÜR PERSPEKTIVEN…
Karriere bei 1&1
klassisch via
jobs.1und1.de
Speziell für Entwickler
Unternehmen kennenlernen
Kontaktnetzwerk knüpfen
Optimalen Job finden