The Architecture of Uncertainty
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Architecture of Uncertainty

on

  • 480 views

Presented at NDC 2013 in Oslo (13th June 2013) ...

Presented at NDC 2013 in Oslo (13th June 2013)
Video available on Vimeo: https://vimeo.com/68331684

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

Statistics

Views

Total Views
480
Views on SlideShare
458
Embed Views
22

Actions

Likes
2
Downloads
0
Comments
0

1 Embed 22

https://twitter.com 22

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Architecture of Uncertainty Presentation Transcript

  • 1. The Architecture of Uncertainty @KevlinHenney
  • 2. 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"
  • 3. 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"
  • 4. struct Date { int year, month, day; };
  • 5. struct Date { int days_since_epoch; };
  • 6. class Date { public: ... private: ... };
  • 7. Public APIs, like diamonds, are forever. Joshua Bloch "Bumper-Sticker API Design" http://www.infoq.com/articles/API-Design-Joshua-Bloch
  • 8. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[index]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 9. public class RecentlyUsedList : List<string> { public override void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 10. public class RecentlyUsedList : List<string> { public new void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 11. public class RecentlyUsedList { public RecentlyUsedList() { Items = new List<string>(); } public List<string> Items { get; private set; } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); Items.Remove(newItem); Items.Insert(0, newItem); } ... }
  • 12. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[index]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 13. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[Count – index - 1]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Add(newItem); } ... }
  • 14. 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
  • 15. 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
  • 16. Analysis Design Code Test
  • 17. Analysis Design Code Test
  • 18. Analysis Design Code Test
  • 19. Walking on water and developing software from a specification are easy if both are frozen. Edward V Berard
  • 20. Expert Proficient Competent Advanced Beginner Novice
  • 21. 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
  • 22. 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
  • 23. Design Design Design Design
  • 24. Design
  • 25. Programming is a design activity. Jack W Reeves "What Is Software Design?"
  • 26. 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?"
  • 27. Properly gaining control of the design process tends to feel like one is losing control of the design process.
  • 28. In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention.
  • 29. It is far better to have an underfeatured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.
  • 30. interface Iterator { boolean set_to_first_element(); boolean set_to_next_element(); boolean set_to_next_nth_element(in unsigned long n) raises(…); boolean retrieve_element(out any element) raises(…); boolean retrieve_element_set_to_next(out any element, out boolean more) raises(…); boolean retrieve_next_n_elements( in unsigned long n, out AnySequence result, out boolean more) raises(…); boolean not_equal_retrieve_element_set_to_next(in Iterator test, out any element) raises(…); void remove_element() raises(…); boolean remove_element_set_to_next() raises(…); boolean remove_next_n_elements(in unsigned long n, out unsigned long actual_number) raises(…); boolean not_equal_remove_element_set_to_next(in Iterator test) raises(…); void replace_element(in any element) raises(…); boolean replace_element_set_to_next(in any element) raises(…); boolean replace_next_n_elements( in AnySequence elements, out unsigned long actual_number) raises(…); boolean not_equal_replace_element_set_to_next(in Iterator test, in any element) raises(…); boolean add_element_set_iterator(in any element) raises(…); boolean add_n_elements_set_iterator( in AnySequence elements, out unsigned long actual_number) raises(…); void invalidate(); boolean is_valid(); boolean is_in_between(); boolean is_for(in Collection collector); boolean is_const(); boolean is_equal(in Iterator test) raises(…); Iterator clone(); void assign(in Iterator from_where) raises(…); void destroy(); };
  • 31. interface BindingIterator { boolean next_one(out Binding result); boolean next_n(in unsigned long how_many, out BindingList result); void destroy(); };
  • 32. Speculative Generality Brian Foote suggested this name for a smell to which we are very sensitive. You get it when people say, "Oh, I think we need the ability to do this kind of thing someday" and thus want all sorts of hooks and special cases to handle things that aren't required. The result often is harder to understand and maintain. If all this machinery were being used, it would be worth it. But if it isn't, it isn't. The machinery just gets in the way, so get rid of it. Martin Fowler Refactoring
  • 33. 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"
  • 34. 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"
  • 35. You have a problem. You decide to solve it with configuration. Now you have <%= $problems %> problems! Dan North https://twitter.com/tastapod/status/342935892207497219
  • 36. typedef ... string;
  • 37. template< typename char_type, typename traits, typename allocator> class basic_string; Trying effective memory management of a container whose representation and management is not fully open to you is like eating with a knife and fork... held with chopsticks... through mittens. Kevlin Henney, "Distinctly Qualified"
  • 38. Henney's Hypothesis For each additional required template parameter, the potential number of users is halved. Matthew Wilson Extended STL
  • 39. If you have a procedure with ten parameters, you probably missed some. Alan Perlis
  • 40. Prediction is very difficultPrediction is very difficult, especially about the future. Niels Bohr
  • 41. Stewart Brand, How Buildings Learn See also http://www.laputan.org/mud/
  • 42. Rate of change
  • 43. package com.sun…;
  • 44. Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result — decreased productivity and little or no increase in code quality. Eric Gunnerson
  • 45. All happy families are alike; each unhappy family is unhappy in its own way. Leo Tolstoy Anna Karenina
  • 46.        Scenario buffering by dot-voting possible changes and then readjusting dependencies
  • 47. A B C D E F              
  • 48. People overvalue their knowledge and underestimate the probability of their being wrong.
  • 49. The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge. Daniel J Boorstin
  • 50. 0. Lack of Ignorance 1. Lack of Knowledge 2. Lack of Awareness 3. Lack of Process 4. Meta-Ignorance Five Orders of Ignorance Phillip G Armour
  • 51. Education is learning what you didn't even know you didn't know. Daniel J Boorstin