Slide 1

Slide 1 text

15 LESSONS FROM 15 YEARS 
 AS A SOFTWARE ARCHITECT Ingo Rammer @ingorammer 
 Co-Founder & CEO at thinktecture

Slide 2

Slide 2 text

Just my personal experiences, not the ultimate sage advise!

Slide 3

Slide 3 text

•  1994 – Web apps with CGI, Perl, Apache, ... •  1996 – Windows Apps (VB et. al) •  1999 – Java backends, Servlets, XML, SOAP, ... •  2001 – .NET à consulting (mainly server side) •  2005 – Client side becomes interesting again •  2009 – Phones (iOS, Android, BB, WP7, ...) •  2010 – HTML5 for Applications

Slide 4

Slide 4 text

Last ten years: consultant to software architects

Slide 5

Slide 5 text

Lessons I‘ve learnt ...

Slide 6

Slide 6 text

Why do projects succeed/fail? People? Technology? ... ?

Slide 7

Slide 7 text

People Complexity Technology

Slide 8

Slide 8 text

People Complexity Technology

Slide 9

Slide 9 text

#1 – Don‘t trust experts! (Speakers, authors, including myself)

Slide 10

Slide 10 text

They don‘t know your context

Slide 11

Slide 11 text

They will be excited about their topic

Slide 12

Slide 12 text

What could be right for 98% of attendees at a conference, could be devastating for your particular project

Slide 13

Slide 13 text

#2 – People affect architecture

Slide 14

Slide 14 text

Where your team comes from (prior experiences, skill levels, shared way of thinking, ...) will influence the suitability of certain architectures

Slide 15

Slide 15 text

#3 - Good for me or for the project?

Slide 16

Slide 16 text

Newest stuff vs. mature and proven

Slide 17

Slide 17 text

Does my current project really need the tech advantage?

Slide 18

Slide 18 text

Or is it just that I will need to use the newest tech to stay current?

Slide 19

Slide 19 text

#4 – Research vs. Development

Slide 20

Slide 20 text

When we just don‘t know the answer, we need to make sure that our customers, employers, and colleagues understand that we are only researching

Slide 21

Slide 21 text

And: We need to make sure that we understand this as well

Slide 22

Slide 22 text

Even six months later! Critically (really!) revisit findings!

Slide 23

Slide 23 text

#5 – Be wary of The Second System

Slide 24

Slide 24 text

First system (with new tech, new approach, new processes): we‘re always very careful

Slide 25

Slide 25 text

Second System: we know it all. We might re-use the things which have worked and do a 180° turn on the things which didn‘t.

Slide 26

Slide 26 text

Reality: either the requirements might be different (and the approaches won‘t work for that reason), or there could be a middle ground instead of the 180°

Slide 27

Slide 27 text

#6 – Some things need to be discussed, others just need to be done

Slide 28

Slide 28 text

Sometimes two, three or four different ways can get a project closer to the target.

Slide 29

Slide 29 text

Finding or waiting for the perfect way might take longer than all negative effects of choosing any of the others

Slide 30

Slide 30 text

Different approaches No No Take any Degree of Perfection

Slide 31

Slide 31 text

#7 – Build what people pay us to build

Slide 32

Slide 32 text

If creating [business software] is boring for us, we need to change to a different customer/ employer/project, but not artificially inflate complexity to make it challenging enough to be worth our while

Slide 33

Slide 33 text

(Otherwise we‘re wasting money and talent)

Slide 34

Slide 34 text

People Complexity Technology

Slide 35

Slide 35 text

#8 – Always observe problem complexity vs. solution complexity

Slide 36

Slide 36 text

If you need to write your own O/R Mapper, DI-Framework, MVC Engine and database for a business application .... you might be missing something

Slide 37

Slide 37 text

#9 – Make it simpler

Slide 38

Slide 38 text

If you haven‘t taken time to make it simpler, it‘s quite likely too complex

Slide 39

Slide 39 text

In 15 years I haven‘t seen a single project fail because of lack of complexity but I‘ve seen (literally!) double-digit millions of EURs lost to too much complexity

Slide 40

Slide 40 text

Can also happen throughout a project: Review architecture and code! Religiously.

Slide 41

Slide 41 text

#9.a – If the solution somebody advocates appears too complex, it quite likely is

Slide 42

Slide 42 text

And, btw, it might be you who‘s advocating it to your team members

Slide 43

Slide 43 text

If you‘re the only one who can describe end-to- end processes in your application, it‘s too complex.

Slide 44

Slide 44 text

Change roles: let your architecture be explained to you by your team in one-on-one‘s. Does it still look the same?

Slide 45

Slide 45 text

#10 – Most of us don‘t need Ebay/Amazon/Google/Bing-Scale

Slide 46

Slide 46 text

A lot of scalability can be achieved quite cheaply today. It‘s just the last 2% which are hard and expensive

Slide 47

Slide 47 text

Fortunately most projects don‘t ever need to go there

Slide 48

Slide 48 text

Even if you do: it‘s usually better to first find out what your market really wants and LATER re- engineer when successful

Slide 49

Slide 49 text

Google, Ebay, Amazon, and most others did it this way, too

Slide 50

Slide 50 text

People Complexity Technology

Slide 51

Slide 51 text

#11 – Code is written to be read

Slide 52

Slide 52 text

Sometimes code has to be really smart

Slide 53

Slide 53 text

Most of the time it has to be readable

Slide 54

Slide 54 text

Because you might not be around five years later

Slide 55

Slide 55 text

Maintainability = Understandability + Discoverability + Consistency + Cohesion - Coupling

Slide 56

Slide 56 text

#12 – Don‘t talk about solutions before understanding the problem

Slide 57

Slide 57 text

It‘s very hard to not fall into the solution-looking- for-a-problem trap “We could really do this using CQRS, ...”

Slide 58

Slide 58 text

Especially in the few weeks after you‘ve read or heard about a new idea/pattern/framework/ approach.

Slide 59

Slide 59 text

Yes, this means: no changes to architecture within four weeks after a conference ;-)

Slide 60

Slide 60 text

#13 – When in doubt, pick the technology you know

Slide 61

Slide 61 text

... instead of taking the newest and Best Thing Ever coming from the vendor

Slide 62

Slide 62 text

Why? it might not be ready, yet. So the question is: is the risk/reward profile positive enough?

Slide 63

Slide 63 text

#14 – There is no silver bullet

Slide 64

Slide 64 text

On all levels, we‘re promised solutions: Quality: TDD, Unit Testing, ... Data: Autosharding, NoSQL, BigTable, ... Dependencies: IoC, DI, EBC, ... Responsibility: CQRS, ... Do they deliver? Are they worth the risks?

Slide 65

Slide 65 text

#15 – There is no good idea which can‘t be used in a totally wrong way

Slide 66

Slide 66 text

Quality: TDD, Unit Testing, ... Data: Autosharding, NoSQL, BigTable, ... Dependencies: IoC, DI, EBC, ... Data Responsibility: CQRS But even classics: O/R Mapping, Event- Based Decoupling, ...

Slide 67

Slide 67 text

The Top #15 #1 – Don‘t follow others! #2 – People affect architecture #3 - Good for me or for the project? #4 – Research vs. Development #5 – Be wary of The Second System #6 – Some things need to be discussed, others just need to be done #7 – Build what people pay you to build #8 – Always observe problem complexity vs. solution complexity #9 – Make it simpler #9.a – If the solution appears too complex, it quite likely is #10 – Most of us don‘t need Ebay/Amazon/Google/Bing-Scale #11 – Code is written to be read #12 – Don‘t think about solutions before understanding the problem #13 – When in doubt, pick the technology you know #14 – There is no silver bullet #15 – There is no good idea which can‘t be used in a totally wrong way Bonus – Shipping is a feature! People Complexity Technology

Slide 68

Slide 68 text

Be pragmatic and honest! Simplicity wins! Don‘t let every hype get you! ... and talk to the business people People Complexity Technology

Slide 69

Slide 69 text

Contact [email protected] Weblog http://weblogs.thinktecture.com/ingo