Philosophy At The Office: Procedure

My first proper entry in this category, and it needs to be said what perspective I come from. I'm a developer working as part of a larger team of developers, as one development team of many in the same project, with business analysts, testers, managers and the client themselves all looking at the product that needs to be built.

The way the procedure seems to go: The client gives the requirements to the business analysts, who translate the requirement into a technical specification. From there the developer builds it as per requirements which the testers keep the developers on task and to specification.

The goal at the end of all this theoretically is working software - the business value is a functional system. So the assumption would be that consequences are all that matter. In this scenario, the time frame and resources should determine procedure. There's more than one way to skin a cat of course, so the inevitability in such a large project is that there's bound to be different people with their own preferences, or heaven forbid have the one way they know to go about things.

In a high-risk project, it makes sense to go for a low-risk procedure. Even if the procedure isn't right for the task at hand. I'm referring to what should make anyone in software development shudder - waterfall. Anyone unfamiliar with the methodology should note what it entails: a procedural manner with a set of clear goals at each step of the way. In effect, it's a managers dream - it allows for monitoring of the entire process.

But therein lies the problem, if the end product is what ultimately that matters then working to minor goals at each step of the way will only be a success if those goals are properly laid out. Otherwise the procedure becomes not about achieving business value but about checking off goals.

The dilemma for the developer is ultimately its their head on the chopping block. They have to manage the expectations of meeting the deadline with business value at the same time as meeting the intermediate goals. The inevitability of such a procedure is that unless the intermediate goals are to do with development (as opposed to functionality) then the system is going to fall over under even the slightest strain.


Imagine building a house, and the requirements including having a kitchen and bathroom. Now from the builders perspective the house needs to have plumbing and electricity wired in, but the time frame doesn't accommodate such requirements. Instead it needs the kitchen in place by Friday. It has to have a dishwasher, a fridge and a sink, as those will be what the owner wants. So until Friday the focus is on having those appliances in, with the builder's progress being measured by them being there. So when Friday comes about and there's no electricity or plumbing, what good is meeting the aesthetic when there's so much behind the scenes not accounted for?

This sounds absurd because it is absurd. When management has their goal on a diswasher being in the kitchen, when the business analysts are specifying that a dishwasher needs to be there and the testers marking solely on the presence of the dishwasher, how can an feature-driven approach succeed? It can't see what is happening behind the scenes nor can it accommodate for it.

The best one could do is quickly rig up some electricity and plumbing for that room in particular. But surely the same electrical circuitry in the kitchen will be in other rooms too. It makes no sense to build a house without getting all the wiring in place, likewise building software component by component can't work without an underlying structure to it all.


It is the hope that reason will win out, that methodology for development is chosen by the circumstances as opposed to familiarity or monitoring. Otherwise there will be pain, as participating in the process and achieving what the client wants become opposite outcomes!