Another day, another argument discussion with a colleague over the common misapprehension that you can have a process with discrete requirements capture, design, development and test phases, yet somehow still claim to be agile. Once again, I tried (with limited success) to explain that you don’t need to do all your designing up front before you start writing code, and that starting to write code almost immediately isn’t ‘hacking’, provided that you are continuously paying attention to good design as you go.
In other words, agile developers do just as much designing as those still following waterfall methods, but we do it at the same time as writing the code.
Reflecting afterwards, I realised that I’ve been phrasing the message the wrong way. As anyone who really ‘gets’ test-driven (and particularly behaviour-driven) development knows, it’s not really about the testing, but about the design process. A waterfall ‘designer’ starts from an understanding of the problem and builds up some kind of model for a solution, which they then pass on to the implementors An agile developer does exactly the same, but the language they use for the model happens to be executable source code rather than documents or UML. This choice of modeling language has the rather large benefit of being testable, and once your design is finished, you’re done. No need for someone to try to interpret and implement it. No scope for misunderstandings between designer and developer. No danger that the design is incomplete, or that part of it turns out to be unworkable.
It’s not that we start writing code and design as we go along.
We are always designing – we just write the code as we go along.
[tags]agile, tdd, bdd[/tags]
3 replies on “Concurrent design and development – a better spin?”
I tend to agree with most of what you’re saying but I think one issue you have missed, which is inherent in a waterfall model, is that designers and developers are not necessarily the same people with the same skills. Yes – a skilled builder could probably build his own house and design it on the fly, but I doubt the greatest works of architecture could have been constructed so.
Of course, building the greatest works of architecture is not necessarily the aim in an IT context – but on the other hand, anything of sufficiently large scale needs shared vision and distribution of skills. I do wonder if design-by-code is the best way to achieve this?
I take your point to some extent, but I’d argue that many of the problems we have in implementing IT are caused by the de-skilling and devaluing of software development.
In my opinion design and development are two sides of the same coin, and should be separated as little as possible. Trying to increase agility while still treating coding as monkey work is doomed, IMO.
As far as architecture and overall design goes, that’s something that is handled by the team as a whole, guided by the most experienced developer/designer/architects.
See Martin Fowler’s articles Is Design Dead? and Who Needs an Architect?
[…] out she was putting together references for her dissertation, and came across a paper which cited some random nonsense I’d posted back in 2007. Small […]