Good design from bad design
Thursday, December 22nd, 2005 at 10:14pm
In my regular trawls through the various RSS feeds that I regularily look through I came across an essay by Scott Berkun. I cannot recall which one I found first but one in particular caught my eye: Why good design comes from bad design.
It has been recognised for quite some time now that most of the issues we have at work now derive from incomplete consideration of how to go from the requirements to code, ie the design. Back in September we formally introduced a design step in our process and provided a couple of examples of the main areas to consider. There was one small comment that said that even the alternatives that were not chosen for the final design should still be documented, including the rationale behind why they were not chosen.
One of the issues (apart from developers still skipping over design) that I have seen is that some of the developers are treating design like a bit of bureaucratic nonsense and spending as little as time as possible on it. On a number of occasions that I have reviewed and then discussed these documents I received a number of “oh yeah” or “that’s a good idea” responses, even when I suggested trivial (but often signifigant) changes such as a different name for a function. (This is where the mentoring aspect of my role that I touched upon yesterday)
This ties in with the Scott’s essay in that I feel that we are not yet experienced enough to know what makes up a good design, maybe never considering the varied nature of the applications we build. I am now more convinced that coming up with multiple designs is critical to getting a good design and it needs to be explicitly part of our process. How can you learn without being able to compare what is ‘good’ against what is ‘bad’?
I am almost hesitant to bring up the procedural versus object-oriented debate at this point but I will anyway… The paradigm chosen for an application is often arbitrary (also more often with a poorly designed interface whatever the paradigm) and I feel that the simple act of coming up with multiple designs can transform it from what the developer is most comfortable with to what is most appropriate. In most cases it should simply be enoigh to select a couple of screens from the application and write out some psuedo-code in each paradigm that will generate the screen… Another important ingredient is to then discuss the result with other (appropriate) team members…
