Do it right the first time

Decisions made in the course of development must balance multiple needs: delivery time, quality, and cost. Over the course of my career, various people have exhorted me (and other developers) to "do it right the first time". The implication is that the team is being rushed, and a longer development effort will yield a better result.

The cynical version of this is "We don't have time to do it properly, but we always have time to do it again".

I know many developers, and not a one wakes in the morning with the thought "today I will do things wrong". Everyone I know wants to do the right thing.

Some folks believe that they are prevented from doing the "right thing" by their managers, or the bureaucracy, or marketing-originated specifications. Yet sometimes we prevent ourselves from doing the right thing.

To "do things right", one needs two things:

1) An understanding of "the right thing"

2) The belief that one has the resources to accomplish it

Inexperienced programmers will do what they think is the right thing, yet may be bad for the long term. They may duplicate code, or create unmaintainable code. It seems the right thing to do at the time, and with their expertise. Seasoned programmers know that code endures and should be written for future developers. Even temporary fixes endure.

Experience and sophisticated knowledge is not sufficient. If one thinks that the effort for the "proper" code is too great, or takes too long, then one might decide to make a set of "improper" changes. Business managers often must decide between multiple options, and sometimes choose compromising solutions. Managers often make choices that differ from those of the technologists.

Sometimes the technologists are right. Sometimes the managers are right. In any given situation, it is hard to tell who is truly right. Sometimes the answer becomes clear with time -- but not always.

Often I find that the proper way to do things requires discipline, care, and knowledge of the business requirements and the underlying technology. And often I find the the right way of doing things uses principles from earlier eras. (For example, the Model-View-Controller design pattern is mostly a separation of concerns, and this ideas was present in many system design methods of the 1960s. COBOL shops knew to separate input-output operations from processing operations; they just didn't use the phrase "MVC".)

So perhaps we should spend less time exhorting our fellow developers to "do the right thing" and a little more time on understanding the work of of predecessors. That might be the right thing to do.