As software developers, we tend to look at the “big picture”, meaning, what the finished product should look like when we are “done” developing.  Our tendencies, in general, are to focus day-to-day, hour-to-hour, and minute-to-minute on how the piece of code we’re working to create fits into the larger landscape.  Although it’s important to have enough perspective on the big picture to know what exactly we are building and what purpose it should serve, if we liken it to building a working machine such as a car, an improperly focused development process is the equivalent of focusing on the whole car while fashioning one of the bolts that fastens the engine to the block.  Focusing on the car as a whole gives you very little perspective on the state of the car in terms of completeness and functionality; especially if multiple engineers are building it.  The typical result is that the bolt doesn’t serve it’s purpose entirely.  Focusing on the car instead of the bolt also has a tendency, at least speaking for myself, to throw you into a tailspin of panic in terms of the fact that “things aren’t getting done fast enough”.  What, effectively, are your options?

1.  Quickly build a bolt.  The car will be on the dealers lots, maybe even ahead of schedule.  It may even sell well at first.  However, with the motor rattling around under the hood, and with the trickle-down effect from this problem, do you think the customer who bought your car the first time will be tempted to buy the new model?  If, for it’s limited lifetime, allows you to glide over crowded streets and get to your destination much more quickly, then the answer would be:  maybe.

2.  Build a good bolt that fits the specs and satisfies the requirements.  Sell your car with pride.  Assuming your building a car to fill a marketable niche, reap the benefits of repeat customers to offset nearly any cost that might have been incurred from building a better bolt, within reason of course.

In terms of software development, option #1 is chosen far more often that option #2.  It’s important to remember that the simile of focus and perspective and the resulting level of quality applies not only to the end product, in our example, the car, but also to us individually; the engineer that built the bolt.  Each of us our effectively are our own enterprise and the results of our labors hang with us for long periods of time.

Getting back to our bolt engineering example, isn’t it more important to focus on, for instance, threading the bolt to create enough clamp force to hold the engine to the block?  Isn’t it more important to make the bolt from the right materials to satisfy weight and strength requirements so that the car doesn’t weigh too much and also so that the act of simply tightening the bolt doesn’t cause it to shear?  Isn’t it more important to have enough perspective on the project to be completely aware of the holes that the bolt will be inserted into so that the bolt is long enough, and so that it will not only fit in the whole, but so that the bolt is the right diameter to keep the engine from moving under stress?

As software developers, we have a distinct disadvantage over other types of engineers in that the parts that comprise our end product are in fact soft and pliable.  Please notice the work disadvantage.  We can change these parts relatively easily once they are made in contrast to an actual, physical bolt in terms of our example.  However, that doesn’t necessarily mean that the bolt can be of poor quality in version 1.0.  You will never fix it later.  Period.