$30 off During Our Annual Pro Sale. View Details »

Why software architects fail. And what to do about it

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.

Stefan Tilkov

October 30, 2018
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. Why Software Architects Fail 10 Diseases You Should Know About

    Stefan Tilkov, INNOQ @stilkov
  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ˈ) ·
  3. @stilkov 1. Over-Generalization Drive

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

    generic solutions
  5. @stilkov Phases in a Developer’s Life

  6. @stilkov 1. The Enthusiastic Developer “This stuff is cool -

    let’s build programs! For real people!”
  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
  8. @stilkov 2. The Disillusioned Developer “Oh. Real people have boring

    problems.”
  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
  10. @stilkov Create Thing Find Thing List Thing Edit Thing Delete

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

    Find Thing List Thing Edit Thing Delete Thing
  12. @stilkov 4. The Disillusioned Architect KISS YAGNI Lean Minimable viable

    product Story focus
  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
  14. @stilkov 5. The “Wise” Architect Answer: It depends. Question: *

  15. @stilkov 2. Domain Allergy

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

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

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

  19. @stilkov Configuration The 
 Generic
 Thing
 Machine Customer Developer

  20. @stilkov The benefits of choices already made Microsoft .NET +

    Visual Studio SAP et. al. Ruby on Rails
  21. @stilkov 3. Obsessive Specialization Disorder

  22. @stilkov Symptom: Believing every problem to be unique, even if

    it’s been solved 1,000 times
  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.
  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
  25. @stilkov 4. Unhealthy Complexity Attraction

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

    simple approaches
  27. @stilkov Benefits of Complexity > Challenging work > New and

    interesting experience > Self-esteem > Community > Barrier to entry > Job security
  28. @stilkov 5. Analysis Paralysis

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

    it
  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
  31. @stilkov 6. Innovation Addiction

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

    get to production
  33. @stilkov Symptom: Using fashionable technology because it’s popular
 (a.k.a. conference-driven

    architecture)
  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
  35. @stilkov Image Credit: Dan Dickinson, https://flic.kr/p/9mUs73

  36. @stilkov 7. Severe Tunneling Fixation

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

    like what I know … Genesis
  38. @stilkov Symptom: Enforcing an architectural approach that clashes with the

    framework, libraries or tools you use.
  39. @stilkov 8. Asset Addiction

  40. @stilkov Symptom: Becoming so attached to a particular tool/library/framework it

    becomes a fit for every problem.
  41. @stilkov 9. Exaggerated Risk Aversion

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

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

  44. @stilkov simple complex easy hard Rich Hickey, “Simple Made Easy”,

    http://www.infoq.com/presentations/Simple-Made-Easy
  45. @stilkov 10. Impact Dissonance

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

    is being delivered
  47. @stilkov Related: Governance Megalomania

  48. @stilkov Symptom: Believing everything has to be approved by you

    to ensure it meets architecture standards
  49. @stilkov What architects want to do Shape strategy 30 %

    Make important decisions 30 % Mentor developers 20 % Explore technologies 20 %
  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 %
  51. @stilkov What architects actually do Do technical stuff 5 %

    Act as salespeople 30 % Try to be involved 35 % Defend architecture 30 %
  52. @stilkov Image Credit: Sean Michael Ragan, http://flic.kr/p/8XEm6L

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

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

  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 %
  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
  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