Since 2010

Coding As a Career Isn't Right for Me

Saturday 21 May 2016

A chap called Tom Reece at

Now my day to day is filled with process. We must break our deliverables into 2 week chunks so that the stakeholders can see our progress and know that we’ll deliver on time. But it’s not on time. Everything must be tested. But it still has bugs. Everything must have thorough documentation. But it quickly gets out of date and we never read it. Ready to release it to the world? You have to submit a Change Request Form and ask someone else, some magical Oz behind a curtain, permission to do that.

Mum's pancakes

Friday 29 April 2016

  • 110g self-raising flour
  • ¼ teaspoon salt
  • 15g margarine
  • 55g sugar
  • 1 beaten egg
  • 70ml milk
  • Lemon essence

Mix flour and salt, and rub in margarine. Mix in sugar, egg, and milk. Add lemon essence.

When to design

Tuesday 19 April 2016

Sandi Metz in the opening chapter of Practical Object-Oriented Design in Ruby: An Agile Primer:

Agile believes that your customers can’t define the software they want before seeing it, so it’s best to show them sooner rather than later. If this premise is true, then it logically follows that you should build software in tiny increments, gradually iterating your way into an application that meets the customer’s true need. Agile believes that the most cost-effective way to produce what customers really want is to collaborate with them, building software one small bit at a time such that each delivered bit has the opportunity to alter ideas about the next. The Agile experience is that this collaboration produces software that differs from what was initially imagine; the resulting software could not have been anticipated by any other means.

If Agile is correct, two other things are also true. First, there is absolutely no point in doing a Big Up Front Design (BUFD) (because it cannot possibly be correct), and second, no one can predict when the application will be done (because you don’t know in advance what it will eventually do).

It should come as no surprise that some people are uncomfortable with Agile. “We don’t know what we’re doing” and “We don’t know when we’ll be done” can be a difficult sell. The desire for BUFD persists because, for some, it provides a feeling of control that would otherwise be lacking. Comforting though this feeling may be, it is a temporary illusion that will not survive the act of writing the application.

BUFD inevitably leads to an adversarial relationship between customers and programmers. Because any big design created in advance of working software cannot be correct, to write the application as specified guarantees that it will not meet the customer’s needs. Customers discover this when they attempt to use it. They then request changes. Programmers resist these changes because they have a schedule to meet, one that they are very likely already behind. The project gradually becomes doomed as participants switch from working to make it succeed to striving to avoid being blamed for its failure.