In the past couple years I’ve done a fair amount of interviewing where I’ve been evaluating candidates on their technical abilities. One of the questions that I routinely ask is what part of a project the candidate would most like working on and I provide the following list of options: Analysis, Design, Construction (Coding), Testing, or Maintenance. So far, no one has picked the “Maintenance” option, no surprise there. The real interesting thing is that most candidates pick “Design” as their favorite part. But when I ask, “What books have you read about Design?” they rarely have an answer. And when I ask further probing questions about how they would go about design, or what they like about it, I often get very nebulous answers at best. I wonder if some people like the IDEA of Design but have actually done very little of it. They think of being creative, brainstorming, white-boarding, or even just of the excitement that sometimes surrounds starting a new project. It might be true that on many projects that is the only kind of thing that is done as part of “design”.
When I think of design, a number of things come to mind. I’d be curious to hear back about how other people think of design. But before I get into what is actually involved in design, I want to address the issue of design being the preferred part of the project. Doing design can be fun, I’ll admit it. The other phases of software development can be fun too. But lets be clear about something: there is also a lot of work that goes into the design of an application. Or at least there should be!
The design phase of an application development project should address the fundamental question of HOW the application will be built. Hopefully, the analysis phase has already addressed the question of WHAT is to be built. The primary output of design should be documents, or UML diagrams or whatever will best communicate the overall structure of the application and interactions between layers and components of the application. So there are two things that make design difficult. The first is making good decisions about how to structure things. The second is clearly communicating those decisions to others on the team. And here’s the catch about design–there may be better decisions and worse decisions, but there are very rarely right and wrong decisions. Designing applications often comes down to trade-offs. Sometimes a design decision is made based on the best available information. And then as the project progresses, more information comes to light. Or maybe business realities change making past design decisions look like “wrong” decisions. The good thing about writing code is that either it compiles or it doesn’t. Either it works or it doesn’t. With design there’s a whole lot more grey area than that.
Here’s another thing that makes design difficult: everyone on the team has a BETTER idea of how things should be structured. Developers often think that their way of doing things is the only RIGHT WAY. One person thinks everything should be a web service and another thinks .NET Remoting is the answer. Someone is used to having UI components bind directly to the database and sees no reason to ever do otherwise. Someone else likes XML and wants everything to be represented as XML. The point is that it is rare to find a developer who is sympathetic to the fundamental difficulty of the trade-offs involved in many of the design decisions. When we become accustomed to doing things in particular ways, we tend to become myopic and see other ways of doing things as wrong. So it often falls to the application designer to work with other developers, to listen to their ideas, to evaluate them, to incorporate them as applicable, to communicate when the ideas are not taken, and at the same time to try to keep a cohesive design in place. This stuff is hard, particularly since much of it is sociological in nature and not in the natural sweet spot for technical folks. This difficulty often pushes designer to one extreme or the other. They tend to become either dictatorial and not really take input from the rest of the team. Or they go in the other direction where there take all input and there ends up being no cohesive design in the end. The application becomes an amorphous blog of code with no discernible design. I’ve worked for both types.
Don’t get me wrong: I really do like doing application design. But I think that doing good application design is actually the hardest parts of a project. Maybe one of the reasons I like it is that it is very challenging.
Part 2 of this article is going to be about what actually goes into application design.