As programmers we are used to solving problems. Usually these problems are technical problems such as working out how to read lots of data in a memory efficient manner or working out how to deal with a background task in a thread-safe way. We are good at thinking of solutions to these problems and we enjoy it.

Sometimes we get other types of problems that are outside of our domain but affect us in equal measure. I’m referring to problems within the organisation. I’m talking about the problem of time pressure.

Every developer has experienced the impatient customer, or deadline-enthusiastic manager who demands that things be done as soon as humanly possible with no actual regard to the work involved. I like to call these blind deadlines. Under these circumstances some developers will feel the pressure of the impending deadline and rush themselves, cutting every corner they can to try and meet the deadline.

The first thing that a rushing developer cuts is their code quality. Rather than think about the design of the code, they go with what ever works or what ever seems to be the quickest method. Essentially quality is traded off for time, resulting in lower quality in a shorter time.

The more experienced developers won’t fall into this trap of rushing themselves because they understand the importance quality and have seen bad code enough times to know that rushing out bad code is the worst possible thing they could do. It’s important to understand and remain aware of the fact that we are acting professionals and must remain professional when under time pressure – not revert back to our undergraduate former selves the night before the project was due.

As a developer, our primary concern is the code we write. A baker doesn’t take unfinished bread out of the oven to produce stock more quickly. A surgeon doesn’t do the quickest job possible in order to reduce the waiting list and developers must not write bad code for the sake of getting the job done quicker.

The reason is simple. It costs a lot more to maintain poor code over an average project lifetime than it does to write good code in the first place. While time is a key factor for almost every job a developer will participate in, it shouldn’t be the driving factor. The time allocated to the job should be carefully calculated by taking into consideration the magnitude of the job and every other known factor (such as a previously calculated velocity in an agile process).

Using a process can help with the problem of blind deadlines. Agile processes focus on breaking the overall task into smaller more manageable pieces – making it easier to estimate the time involved in completing a particular job.

In short, be professional, don’t rush and focus on what matters – your code quality. Customers or managers will quickly see the benefit of high quality code.