Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.
Speculative design
How do you know when you're finished?
From Agile Answers comes the following paragraph (emphasis added), which is pretty timely given the conversations I've had recently.
Do the simplest thing for the task at hand
Originally a pushback against speculative development (particularly in code frameworks), this guideline is very easy to distort if you want to attack agile methods. Developing incrementally does not (in my opinion) mean taking your brain out before starting. I generally have an idea of where I'm going when developing, based on knowledge and experience. I use that mental roadmap to decide how to write the next test. Sometimes I'll skim through and try a quick implementation of part of a feature to see if it looks right (quick meaning minutes, not days). Then I'll write the tests that exercise my intended implementation, which will probably change it slightly to make it more testable. Code is clay, not marble. Or at least it should be.
For me, the logical extension to this is to talk about iterative and incremental development in general. Take a common component. With a traditional waterfall methodology, common components are typically planned, designed and built upfront before being baselined as complete and ready to use. While this works, problems can arise later on in the project when you realise that the common component doesn't quite support what you need or, worse, provides functionality that you're never going to need. This happens because you speculated what was needed too early.
Iterative and incremental development provides a way for you to "do the simplest thing for the task at hand", yet it's easy for teams to fall into the trap of doing speculative design because they like to have a fully planned out schedule before starting off on the project, which is contrary to the adaptive planning approach recommended for iterative/agile development. As Darren says, you don't take your brain out before starting an incremental project - you still need to know where you're going.
Those common components will get built, but they'll be built when they're needed and, as a result, they'll support exactly the features that are needed. If you do build common components outside of the context in which they will be used, what do you say when somebody asks you whether they're finished? How do you know when you're finished?
