Code First, or Design First
This post is pretty much a response to this blog post from 18F. 18F Discussion: Should Project Teams Code First Or Design First?. While it pretty much stands alone as well, you might want to go read the first article to put thing in context.
Let me put my old guy hat on for a bit. I’ve been doing this a long time and the answer has always been design first. I think that developers today get too tied up with the power of a strong framework. Yes, your framework and your skills are good enough that you can do this in a few hours and have something passable for the client to view. The question is really, should you? And I think (rather strongly) the answer is no.
The underlying problem is that writing code is slow. Drawing pictures on paper (or whiteboard) is fast. If I sketch something out and it’s bad, or has bad parts, I just throw the paper out and start over again. Maybe incorporate good things from the initial draft and leave out the bad things.
I’ve always instilled in my teams the power of the design review. Once you’re done with a design, sit down and talk to the rest of the team about it. They’ll hopefully help you find things that are bad, things where their experience may give you feedback you wouldn’t have seen yourself, etc. And the best part is, the only thing you’re invested in is the documentation. It’s easy to move words around in a document, or move blocks in a diagram.
With code that even works a little bit, there is an impetus. You’ve invested time in getting it to work this well, you’re going to be hesitant to change it, which can keep you closed minded when discussing alternative solutions. Or even worse, the customer sees your demo and latches on to it, thinking it’s only a trivial amount of work to get it to launch.
When I worked at Hillcrest Labs, we had the prototype that wouldn’t die. It was all fake stuff that would only ever run on a PC (we were targeting an embedded platform). It took a lot of work to convince our management that we needed to concentrate on only working on the real product and remove everyone from working on the prototype. And eventually we did, but it was an uphill battle.
We can also talk about the quality of prototype code versus production code. The thinking is “This is just a prototype, I don’t need to handle this error here.” Which means that when it becomes time to do it for real, you either go through all your existing (crappy) code and try to patch it up to production quality, or you start over and all your work was for naught.
So, while an interesting article, I don’t really think there is really much of a discussion. Coding first just has too many risks.