TechEd 2006: On the importance of working within set requirements

Requirements and architecture

At the TechEd architecture preconf Ron Jacobs talked about what requirements are, and how they help define the goal for what you are trying to achieve. He drew a parallel to playing soccer on a field with no goal posts, no lines, no constraints whatsoever. Just starting to play, and figuring out the goal positions and so forth as you go along. Obviously this would simply not make any sense. However, people seem to believe it does so when making software. Especially from an architect’s point of view it is important to understand what we’re trying to achieve at least on a hight level before we can decide how to design it. If the architecture is broken in a sufficiently bad way it might cause the whole system to go back to the drawing board (suck on that, XP!). And how might this happen? By not understanding the business problems well enough and screwing up the requirements gathering and therefore designing an architecture to solve the wrong problems. Therefore a certain amount of up-front design is necessary.

But often enough it also happens that architects and developers get too worried about the requirements, and they let this block them from designing the solution. They start worrying about every little bit of unknown area, and refuse to touch it until it’s been specified. So this can really hit two different extremes. Either you do no design because you don’t know the requirements and just start coding, or you get anxious about not knowing everything so you produce nothing.

Learning to balance this line is key to becoming a good developer or architect, IMHO. You need to get enough confidence in yourself to trust that you will find a solution to problems that come up and just get started on designing those parts that can be designed. Focus first on those areas that you do understand, and use that as a way to get going and to create something that you can show the customer and get feedback on. This way the rest of those requirement will start to appear, and you can incrementally improve your design. Experience will teach you which types of things you need to know up front and which kinds of things it is ok to defer until you have more information.

Getting people to commit to the project

One of the really key things we’re trying to improve in our organization right now is to get everyone in a project to have a shared understanding of what the project is supposed to achieve. This sound like something really obvious, but still it is one of the most simple things that companies fail to get right. I’ve worked on many project where management has thought that everyone involved knows the goal of the project, but in reality none of the developers really do. Note that this also includes times when I have been part of the management for these projects.

In a situation like this it’s impossible for them to make good decisions about how to develop something or on how much time to spend on it, simply because they lack context. And that results in a lack of commitment to the project (sometimes I think that developers believe that “commit” is what you do when you check in code to version control). Without commitment and context you will be stuck with a bunch of people that can make no decisions on their own and can only perform exactly the tasks you give them. But by getting them more involved and by giving them context you allow them to contribute to the project beyond simply performing precisely given tasks. And you are sure to benefit from it.

All it takes to sow that first seed of project commitment in all the project members is to create a good vision statement and sit down with the whole team an talk through it. Discuss it and make sure everyone understands it. After this they will feel a lot more connected to the project because they have context. And the commitment will follow.