QCon 2007 Notes: Modifiability

Martin Fowler and colleagues, Modifiability, or, Is there Design in Agility?

  • There’s confusion between the quickest thing and the simplest thing that will still work in the longer term
    • MF reports Kent Beck as saying, on seeing some awful code written on the “quickest” model, “Yes, but the phrase is ‘the simplest thing’, not ‘the stupidest thing'”
  • Be open to the importance of things not predicted from the outside
    • when adding a new process for collecting data about clients, they realized after a bit that the useful model was not the data, but the collection of the data. (We had a similar realization in the Batch add-on for … are we still calling it “the super secret project”?)
  • Defer any decision to the last responsible moment
    • Erik Doernenburg [ED]: But recognize the point at which you have to make a decision
    • [Microsoft’s Erik Meijer echoed this sentiment in his keynote]
  • Always know and be able to articulate the model
    • If the system changes, change the model.
    • Because if you can’t articulate it, you don’t really know what you’re doing.
    • [Likewise knowing and being able to articulate the design, and so forth all the way down]
  • Be prepared to push back on documentation “required” up front
    • On one project, 13 architecture documents were required up front. Of those, some were required up front, some were provided up front but were provisional and subject to change, and some were maintenance documents that were delivered (and accepted) at the end.
  • Keep the domain model clear of implementation details at all costs
    • Dan North [DN]: Things are good if the developers are talking and you can’t tell if they’re talking about code objects or business objects
  • Test-driven systems tend to drive better design and architect themselves to a greater extent (DN)
  • Cheap scaffolding can help isolate/encapsulate the bits we don’t want to care about yet (MF)
    • i.e., if you’re mostly working on the data model, simple html pages rather than something more complicated can make it easier for the business people to see what we mean without clouding the focus
  • If you think you need to break encapsulation, either you’ve got the model wrong or you haven’t got the right solution yet
    • Hide as much as possible for as long as possible
    • If you seem to be testing implementation, panic, then consider Behaviour-Driven Development
  • Code should be almost readable by a lay business person
    • Maybe not the code-language details, but at a minimum variables and method names should be clear
  • Agile can be used as an excuse not to do the basic right thing. Don’t.
    • Software is going to evolve anyway, in maintenance and cruft. Agile is directing that evolution.
  • It is important to grow great developers(MF)
    • It is really easy to double the productivity of a programmer in a six-month agile project
  • MF on the definition of architecture:
    • As much as possible, make decisions reversible
    • This boils down to “get rid of architecture”

For me, this was the key session of the whole conference. We all know that it is difficult to follow all of these principles on a real-world project all the time, but we also all know that the costs of breaking them are in the longer term always too high. For any new project these should be watchwords, and for any older project that has broken one or more of them, they should be signposts back to a healthy project that has good velocity, happy developers, and happy business people.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply