Why software architects fail. And what to do about it

We’ve all seen them: Ambitious projects, starting out with grand visions, ending up as costly lessons in what not to do, leaving behind the ruins of promising paradigms, technologies, tools, and careers. But why do architecture approaches sometimes hurt instead of providing value? Why has “software architect” become a negative term for some people? And what can we do to improve our own work? We’ll look at some of the most common pitfalls that ensure you’ll come up with a disaster, and discuss how they can be avoided.

Transcript

1. Why Software Architects Fail
   10 Diseases You Should Know About
   Stefan Tilkov, INNOQ
   @stilkov
   

   View Slide

2. @stilkov
   n. A pathological condition of a part, organ, or
   system of an organism resulting from various
   causes, such as infection, genetic defect, or
   environmental stress, and characterized by an
   identifiable group of signs or symptoms.
   n. A condition or tendency, as of society, regarded
   as abnormal and harmful.
   n. Obsolete Lack of ease; trouble.
   dis ease (dĭ-zēzˈ)
   ·
   

   View Slide

3. @stilkov
   1. Over-Generalization Drive
   

   View Slide

4. @stilkov
   Symptom: Seeing
   commonalities in
   everything and turning
   them into generic
   solutions
   

   View Slide

5. @stilkov
   Phases in a Developer’s Life
   

   View Slide

6. @stilkov
   1. The Enthusiastic Developer
   “This stuff is
   cool - let’s build
   programs! For
   real people!”
   

   View Slide

7. @stilkov
   Boring, boring, boring.
   Create Customer
   Find Customer
   List Customers
   Edit Customer
   Delete Customer
   Create Order
   Find Order
   List Orders
   Edit Order
   Delete Order
   Create Product
   Find Product
   List Products
   Edit Product
   Delete Product
   

   View Slide

8. @stilkov
   2. The Disillusioned Developer
   “Oh. Real people
   have boring
   problems.”
   

   View Slide

9. @stilkov
   Create Customer
   Find Customer
   List Customers
   Edit Customer
   Delete Customer
   Create Order
   Find Order
   List Orders
   Edit Order
   Delete Order
   Create Product
   Find Product
   List Products
   Edit Product
   Delete Product
   

   View Slide

10. @stilkov
    Create Thing
    Find Thing
    List Thing
    Edit Thing
    Delete Thing
    

    View Slide

11. @stilkov
    3. The Enthusiastic Architect
    “Generic solutions! Cool!”
    Create Thing
    Find Thing
    List Thing
    Edit Thing
    Delete Thing
    

    View Slide

12. @stilkov
    4. The Disillusioned Architect
    KISS
    YAGNI
    Lean
    Minimable viable product
    Story focus
    

    View Slide

13. ‘
    ‘
    @stilkov
    When you go too far up, abstraction-wise,
    you run out of oxygen. Sometimes smart
    thinkers just don't know when to stop,
    and they create these absurd, all-
    encompassing, high-level pictures of the
    universe that are all good and fine, but
    don't actually mean anything at all.
    These are the people I call Architecture
    Astronauts.
    Joel Spolsky
    “Don’t Let Architecture Astronauts Scare you”, http://www.joelonsoftware.com/articles/fog0000000018.html
    

    View Slide

14. @stilkov
    5. The “Wise” Architect
    Answer: It depends.
    Question: *
    

    View Slide

15. @stilkov
    2. Domain Allergy
    

    View Slide

16. @stilkov
    Symptom: Treating the
    domain as a negligible
    nuisance
    

    View Slide

17. @stilkov
    Application
    (100%)
    Configuration
    10%
    The 

    Generic

    Thing

    Machine
    90%
    

    View Slide

18. @stilkov
    80% 20%
    Functionality:
    320%
    80%
    Time/Effort:
    

    View Slide

19. @stilkov
    Configuration
    The 

    Generic

    Thing

    Machine
    Customer
    Developer
    

    View Slide

20. @stilkov
    The benefits of choices already made
    Microsoft .NET + Visual Studio
    SAP et. al.
    Ruby on Rails
    

    View Slide

21. @stilkov
    3. Obsessive Specialization
    Disorder
    

    View Slide

22. @stilkov
    Symptom: Believing every
    problem to be unique, even
    if it’s been solved 1,000
    times
    

    View Slide

23. @stilkov
    Task: Read a file of text,
    determine the n most frequently
    used words, and print out a
    sorted list of those words along
    with their frequencies.
    

    View Slide

24. @stilkov
    Donald Knuth Doug McIlroy
    Dr. Drang, http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/
    10-page literal
    Pascal program,
    including
    innovative new
    data structure
    tr -cs A-Za-z '\n' |
    tr A-Z a-z |
    sort |
    uniq -c |
    sort -rn |
    sed ${1}q
    

    View Slide

25. @stilkov
    4. Unhealthy Complexity
    Attraction
    

    View Slide

26. @stilkov
    Symptom: Being so smart
    you can’t be bothered by
    simple approaches
    

    View Slide

27. @stilkov
    Benefits of Complexity
    > Challenging work
    > New and interesting experience
    > Self-esteem
    > Community
    > Barrier to entry
    > Job security
    

    View Slide

28. @stilkov
    5. Analysis Paralysis
    

    View Slide

29. @stilkov
    Symptom: Taking longer to
    evaluate than to actually
    do it
    

    View Slide

30. @stilkov
    Vendor Selection
    Collect and agree on requirements
    Week 0
    Conduct market research
    Week 8
    Send out RFP to selected vendors
    Week 10
    Evaluate responses, create shortlist, start PoC
    Week 14
    Evaluate PoC results, recommend vendor X
    Week 20
    Accept your CEO picked vendor Y
    Week 26
    

    View Slide

31. @stilkov
    6. Innovation Addiction
    

    View Slide

32. @stilkov
    Symptom: Things become
    progressively less fun the
    closer you get to
    production
    

    View Slide

33. @stilkov
    Symptom: Using fashionable
    technology because it’s popular

    (a.k.a. conference-driven
    architecture)
    

    View Slide

34. ‘
    ‘
    @stilkov
    Mindful choice of technology
    gives engineering minds real
    freedom: the freedom to
    contemplate bigger questions.
    Technology for its own sake is
    snake oil.
    Dan McKinley

    http://mcfunley.com/choose-boring-technology
    

    View Slide

35. @stilkov
    Image Credit: Dan Dickinson, https://flic.kr/p/9mUs73
    

    View Slide

36. @stilkov
    7. Severe Tunneling Fixation
    

    View Slide

37. ‘
    ‘
    @stilkov
    I know what I like
    And I like what I know …
    Genesis
    

    View Slide

38. @stilkov
    Symptom: Enforcing an
    architectural approach
    that clashes with the
    framework, libraries or
    tools you use.
    

    View Slide

39. @stilkov
    8. Asset Addiction
    

    View Slide

40. @stilkov
    Symptom: Becoming so
    attached to a particular
    tool/library/framework it
    becomes a fit for every
    problem.
    

    View Slide

41. @stilkov
    9. Exaggerated Risk Aversion
    

    View Slide

42. @stilkov
    Symptom: Sticking with
    horrible, horrible,
    HORRIBLE tools because
    they’re there
    

    View Slide

43. @stilkov
    Symptom: Confusing
    “easy” with simple,
    creating accidental
    complexity
    

    View Slide

44. @stilkov
    simple
    complex
    easy
    hard
    Rich Hickey, “Simple Made Easy”, http://www.infoq.com/presentations/Simple-Made-Easy
    

    View Slide

45. @stilkov
    10. Impact Dissonance
    

    View Slide

46. @stilkov
    Symptom: Becoming too
    detached from the actual
    system that is being
    delivered
    

    View Slide

47. @stilkov
    Related:
    Governance Megalomania
    

    View Slide

48. @stilkov
    Symptom: Believing
    everything has to be
    approved by you to ensure
    it meets architecture
    standards
    

    View Slide

49. @stilkov
    What architects want to do
    Shape strategy
    30 %
    Make important decisions
    30 %
    Mentor developers
    20 %
    Explore technologies
    20 %
    

    View Slide

50. @stilkov
    What others think architects do
    Slow down development
    20 %
    Pick the wrong tools
    20 %
    Refuse to learn from devs
    20 %
    Define annoying rules
    40 %
    

    View Slide

51. @stilkov
    What architects actually do
    Do technical stuff
    5 %
    Act as salespeople
    30 %
    Try to be involved
    35 %
    Defend architecture
    30 %
    

    View Slide

52. @stilkov
    Image Credit: Sean Michael Ragan, http://flic.kr/p/8XEm6L
    

    View Slide

53. @stilkov
    I don’t have an answer …
    

    View Slide

54. @stilkov
    … so here’s one, anyway
    

    View Slide

55. @stilkov
    An Architect’s Success Formula
    Dogma and rules 10 %
    Experience 20 %
    Pragmatism 20 %
    Flexibility 10 %
    Minimalism 10 %
    Trends and future needs 10 %
    Experiments & PoCs 10 %
    Hands-on participation 10 %
    Vendor advice 0 %
    

    View Slide

56. www.innoq.com
    innoQ Deutschland GmbH
    Krischerstr. 100
    40789 Monheim am Rhein
    Germany
    +49 2173 3366-0
    Ohlauer Str. 43
    10999 Berlin
    Germany
    +49 2173 3366-0
    Ludwigstr. 180E
    63067 Offenbach
    Germany
    +49 2173 3366-0
    Kreuzstr. 16
    80331 München
    Germany
    +49 2173 3366-0
    innoQ Schweiz GmbH
    Gewerbestr. 11
    CH-6330 Cham
    Switzerland
    +41 41 743 0116
    That’s all I have.

    Thank you!
    Stefan Tilkov
    stefan.tilkov@innoq.com
    @stilkov
    +49 170 471 2625
    

    View Slide

57. www.innoq.com
    OFFICES
    Monheim
    Berlin
    Offenbach
    Munich
    Zurich
    FACTS
    ~125 employees
    Privately owned
    Vendor-independent
    SERVICES
    Strategy & technology consulting
    Digital business models
    Software architecture & development
    Digital platforms & infrastructures
    Knowledge transfer, coaching & trainings
    CLIENTS
    Finance
    Telecommunications
    Logistics
    E-commerce
    Fortune 500
    SMBs
    Startups
    

    View Slide