This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 90+ Q&A sites.

Flot2011 Asks:

I find myself pondering over this question again and again. I want to do things the right way: to write clean, understandable, and correct code that is easy to maintain. However, what I end up doing is writing patch upon a patch just because there is no time, clients are waiting, a bug should be fixed overnight, the company is losing money on this problem, a manager is pressing hard, etc.

I know perfectly well that in the long term I am wasting more time on these patches, but as this time spans months of work nobody cares. Also, as one of my managers used to say: "we don't know if there will be a long term if we don't fix it now."

I am sure I am not the only one entrapped in these endless real/ideal choice cycles. So how do you, my fellow programmers, cope with this?

Related: "Why are software schedules so hard to define?"

A happy medium?

Fergus Morrow Answers (3 votes):

Make it work, then make it perfect.

I may draw some flack for this—but if time is of the essence, then your main priority should be to get it working, simple as that. Comment extensively about the shortcomings in your code and make a note of what you've done in any project/time management software you're using. Hopefully this will give you more time to return to these issues and make them perfect.

Obviously there is no absolute correct answer to this, but it's an answer I try and stick to. You may not find it suited to your current work style though. Which leads me on to the alternative...

Find a method that works for you; and then stick with it. Everyone has their own way of dealing with projects and there's no "one size fits all" approach. Find an approach, and make it yours.

Don't make cutting corners a policy

Shane Answers (1 vote):

I see my job as providing the best quality software that is possible within the time constraints allowed for the project. If I am concerned that the level of quality will be low, then I will engage the project owner. I describe my concerns and discuss the potential risks of deploying the software in that state. One of 3 things will happen at this point:

The project owner will not want to accept the risks and will move the schedule back to allow us to spend more time on software quality. The project owner will not want to accept the risks but cannot move the schedule back. If this happens, then we need to negotiate on what features/functionality to remove from project scope in order to spend more time on software quality for the main parts of the application. The project owner will accept the risks and the low quality software will go out on schedule. Sometimes the business risk of deploying nothing (or deploying late) is much greater than the business risk of deploying low quality software, and only the project owner can make that decision.

Writing software is a lot like painting a portrait. It is impossible to say that a portrait is done "right" or "perfectly." Perfect is the enemy of done. You could literally spend 1 month working on a single method and it still might not be considered "perfect" by some. My job is to paint a portrait that the customer is happy with.

Related: "What to plan before starting development on a project?"

Weigh the costs

BillThor Answers (79 votes):

The optimal balance may be to spend as much extra time doing it right as you would waste fixing the bugs you eliminate by doing it right. Avoid gold-plating the solution. In most cases the Volkswagen solution done right is as good as the Cadillac solution. You can usually upgrade later when it is proven you need the Cadillac.

Fixing code that hasn't followed best practices often take much longer. Trying to find where the null is coming from when the call looks like a.b.c.d.e(), can take a long time.

Applying DRY and reusing existing code is usually much faster than coding and testing yet another solution. It also makes it easier to apply changes when they do occur. You only need to change and test one set of code, not two, three, or twenty.

Aim for solid basic code. A lot of time can be wasted trying to make it perfect. There are best practices that lead to code which is fast, but not necessarily the fastest it could be. Beyond that, trying to anticipate bottlenecks and optimize the code as it is built can be wasted time. Even worse, the optimization may slow the code down.

Whenever possible, provide the minimal working solution. I have seen weeks wasted gold plating solutions. Be extremely careful about scope.

At least the used car salesman knows he's lying

Akira71 Answers (63 votes):

Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all these checks and balances, we suffer from the same problem you do.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or demand change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen. All sorts of little things can culminate in a situation where we are forced into the conundrum of "do it right" or "do it ASAP." Almost always, we are forced to "do it ASAP."

As software craftsmen, developers, programmers, people who code for a job, it is our natural inclination to "do it right." "Do it ASAP" is what happens when we work to survive, as most of us do. The balance is hard.

I always start by approaching executive management (I am Director of Software Development and an active developer in that group) to defend the schedule, team, and work being done. Usually at that point I'm told the customer has to have it now and it has to work. When I know there is no room for negotiation or give, I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customer's need to get it ASAP, but something will go and it will get pushed into another sprint. This is almost always OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse, and timelines are getting shorter, then you are in a different situation than what I describe. In that case current or past mismanagement, bad development practices that led to poor code quality, or other factors may be taking you on a death march.

My opinion here is to do your best to defend good code and best practices to start pulling your company out of the trenches. If there isn't a single colleague willing to listen or go to bat for the group against management, then it might be time to start looking for a new job.

In the end, real life trumps all. If you are working for a company that needs to sell what you are developing, then you will encounter this trade-off daily. Only by striving to achieve good development principles early on have I been successful at staying ahead of the code quality curve.

The push and pull between developers and salesmen reminds me of a joke. "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go.

Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.

