The Architecture of Uncertainty - Kevlin Henney - Agile SG 2013

Presented in Agile Singapore Ralph Johnson defined architecture as "the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other". Given our inability to tell the future how can we design effectively for it? Much classic project management thinking is based on the elimination of uncertainty, and advice on software architecture and guidance for future-proofing code often revolves around adding complexity to embrace uncertainty. In most cases, this is exactly the opposite path to the one that should be taken.

The talk looks at how uncertainty, lack of knowledge and options can be used to partition and structure the code in a system.

Transcript

1. The Architecture of Uncertainty @KevlinHenney
4. When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How do I design so that the choice between A and B is less significant?" The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B. Kevlin Henney "Use Uncertainty As a Driver"
5. We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. David L Parnas "On the Criteria to Be Used in Decomposing Systems into Modules"
6. struct Date { int year, month, day; };
7. struct Date { int days_since_epoch; };
8. class Date { public: ... private: int year, month, day; };
9. class Date { public: ... private: int days_since_epoch; };
10. class Date { public: ... private: ... };
11. Public APIs, like diamonds, are forever. Joshua Bloch "Bumper-Sticker API Design" http://www.infoq.com/articles/API-Design-Joshua-Bloch
12. All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. Grady Booch
13. Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other. Ralph Johnson
14. Analysis Design Code Test
15. Analysis Design Code Test
16. Analysis Design Code Test
17. Walking on water and developing software from a specification are easy if both are frozen. Edward V Berard
18. Expert Proficient Competent Advanced Beginner Novice
19. The "defined" process control model requires that every piece of work be completely understood. Given a well- defined set of inputs, the same outputs are generated every time. Ken Schwaber Agile Software Development with Scrum
20. The empirical process control model, on the other hand, expects the unexpected. It provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable results. Ken Schwaber Agile Software Development with Scrum
21. Design Design Design Design
22. Design
23. Programming is a design activity. Jack W Reeves "What Is Software Design?"
24. Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be. Jack W Reeves "What Is Software Design?"
26. Properly gaining control of the design process tends to feel like one is losing control of the design process.
27. You have a problem. You decide to solve it with configuration. Now you have <%= $problems %> problems! Dan North https://twitter.com/tastapod/status/342935892207497219
28. The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork. Kevlin Henney "Simplicity before Generality, Use before Reuse"
29. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, long-winded interfaces, and not- quite-right abstractions. Kevlin Henney "Simplicity before Generality, Use before Reuse"
30. If you have a procedure with ten parameters, you probably missed some. Alan Perlis
31. Prediction is very difficult Prediction is very difficult, especially about the future. Niels Bohr
34. Stewart Brand, How Buildings Learn See also http://www.laputan.org/mud/
35. Rate of change
37. package com.sun…;
39. A B C D E F               
41. People overvalue their knowledge and underestimate the probability of their being wrong.
42. Education is learning what you didn't even know you didn't know. Daniel J Boorstin