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.

One thing I’ve realized in my career is that there is always time to do it right. Yeah, your manager might be pushing. The client might be pissed. But they don’t know how long things take to do. If you (your dev team) don’t do it, it’s not getting done; you hold all of the leverage.

Because you know what will really cause your manager to push you or your client to be pissed off? Poor Quality.

This boils down to what I’ve started thinking of as “The Eternal Conflict” (between business and engineering). I don’t have the solution as it’s a problem that never goes away but you can do stuff to help mitigate.

• Communicate Value

What people often don’t realize is that as engineers we’re just assuming the problem of “successful business” is always a given. We want our code to be nice and neat and maintainable so that we can add new features and tweak existing ones rapidly and with a minimum of customers doing QA for us by discovering bizarre fringe cases that would have been thwarted by better code. Keeping customers and maintaining a competitive edge with features and finesse nobody else can produce fast enough are both business wins that good code directly contributes to and inform much of the reason we want better code in the first place.

So spell it out. “We want to do X in our codebase because if we don’t it will impact business negatively due to Y” or ” …because it will enhance our ability to stay competitive by improving our ability to turn new improvements and features around faster.”

And do your best to try and get tangible evidence that improvements are working. If improving some subset of an app resulted in faster feature/improvement, check whatever backlog tool you might be using for evidence thereof and point it out at appropriate meetings.

• Get the Team on the Same Damn Page

Egos are often a problem. One thing engineering teams need very badly is to establish the value of having some kind of agreed upon consistent approach to solving certain types of problems over everybody doing their own cup of Kool Aid d’jour because they know better. It’s okay to believe the other guy’s preference is worse than yours but value consistency over being more right if his approach is workable and it’s an argument you can’t win. Compromise for the sake of consistency is key. When things are consistent it’s harder to do them wrong since the consistent established way will usually also be the fastest way.

• Pick the Right Tools

There are two schools of frameworks/toolsets/libraries/whatever. “Set 99% of it up for me so I have to know/do very little” vs. “stay out of my way when I don’t want you there, but help me DIY very rapidly and consistently with stuff that I actually want to use on the carrot rather than stick principle.” Favor the second one. Flexibility and granular control should never be sacrificed at the altar of rapid turnaround because to biz, “we can’t do this because our own tools won’t let us” is never an acceptable answer and the question will always come up for non-trivial/disposable product engineering. In my experience, inflexible tools almost always get busted wide open or worked around inelegantly and make a big giant unmaintainable mess. More often than not, the flexible/easier to modify solutions are just as or very nearly as fast in the short term, regardless. Fast, flexible, and maintainable are possible with the right tools.

• FFS, If Engineers Don’t Decide, at Least Get Engineer Input on Picking the Tools

I get the sense this is a developer-perspective question but I’ve been in far too many situations where technology decisions were made with zero engineer input. What the Hell is that? Yes, somebody ultimately has to make the final call, but get some qualified opinions if you’re a non-technical manager, not what some sales guy or demo site says about its own products. Anything promising to save you money because people don’t need to be as smart or because it protects developers from themselves is a filthy, dirty lie. Hire talent you can trust. Spell out to them what you want from a stack or other tech solution and take their input seriously before deciding what tech bandwagon to jump on.

• Focus on Design Over Implementation

Tools are for implementation and as such they can help you, but first priority has to be the architecture regardless of whatever set of toys you have for building that architecture. At the end of the day KISS and DRY and all excellent philosophies that extend from those matter more than whether it’s in .NET or Java or perhaps something that’s both free AND doesn’t suck.

• Log Your Concerns

When the biz-side insists you do it the bad way, save that e-mail, especially the part where you said why it would cost you. When all of your predictions come true and serious business-damaging problems result, that’s when you’ve got a big pile of arguments for taking engineer concerns more seriously. But time things carefully. In the middle of the blazing inferno is a bad time for an “I-told-you-so” on following fire code. Put the fire out, and bring your list of previously ignored concerns to a retrospective meeting/conversation, and try to keep the focus on engineering concerns expressed and ignored and the reasoning you understood why they were being ignored, not the names of the actual people making the decision to ignore. You’re an engineer. Stay on the problems, not the people. “We expressed concern over X because we were afraid it would lead to Y problems. We were told Z and to put off dealing with it.”

There is only one solution. Reserve around 10-20% of project/work time for refactoring. If it’s difficult to convince the management that it is a justifiable task give them the only real argument: without refactoring the cost of code maintenance will grow exponentially over time. It’s good to have a few metrics/articles/research results to back up this thesis during the meeting with the manager 🙂

Edit: there are a few good resources on “refactoring vs rising costs of maintenance” mentioned in this whitepaper: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Whenever you have time for doing something right, use it – write the best code you can, and improve it steadily. Don’t make your job harder by beeing sloppy and introducing technical debt when there is no need to.

Emergency calls for fixing a severe bug are no things you can control by yourself, when they occur, you have to react ASAP, that’s life. Of course, if you are under the impression that your whole job consists of emergency calls, and you have never enough time for doing things right, then you are on a road to burn-out and should talk to your boss.

If that does not help, there is still “Scotty’s strategy” to get enough time for doing things right: multiply all your estimates by a factor of 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

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:

1. 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.

2. 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.

3. 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 “perfect”. Perfect is the enemy of done. You could literally spend 1 month working on a single method and it still not be considered “perfect” by some. My job is to paint a portrait that the customer is happy with.

This won’t work in every case, but I have had some luck using this strategy if the problem is a broken production problem that must be urgently fixed. Estimate the time to do a quick fix to get production running and the time to do the quality fix for the future. Present the estimates to your boss/client and get the time approved for both. Then you do the quick fix to get production runnning and a long term fix immediately therafter when the urgent time pressure is off. I find that if I present it as I need this time to get the job done right, but I can put a temporary fix in place until I can do that, that my clients seem to like that approach. It gets prod running again and it gets the long term need taken care of.

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.

I spent some time working on project that should have taken six months. When I joined it had been in progress for a year-and-a-half. The project lead had asked the project manager one question at the start: “Do you want me to do it right or be responsive?” In one week, a feature was implemented Monday, Wednesday, and Friday; Tuesday and Thursday the feature was removed.

EDIT: When the code is done to a satisfactory level, leave it. Don’t go back to fix it if you come up with a better way to do it. If you must make yourself a note. If changes are required, review your idea and implement it then if it still makes sense.

If there are places where you would implement extensions for upcoming features, don’t implement the extensions. You could leave a marker comment to remind you where to make the changes.

Make it work then make it perfect

I may draw some slack 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…

Just 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.

“Doing it right” means making the right tradeoffs for a particular situation. Some of them are:

1. Development time and cost
2. Ease of reading, debugging, and updating the code later (everything from variable names to architecture)
3. Thoroughness of the solution (edge cases)
4. Speed of execution

Obviously, if a piece of code will be used once and thrown away, #2 can be sacrificed for any of the others. (But beware: you may think you’re going to throw it away, then find you have to keep using and maintaining it, at which point it will be harder to convince people to give you time to improve something that “works”.)

If you and/or your team are going to keep using and updating some code, taking shortcuts now just means slowing yourselves down later.

If you are currently delivering buggy code (weak on #4) and taking a long time to do it (weak on #1), and it’s because you’re trying to update code that was weak on #2, well, you’ve got a solid, pragmatic argument for changing your practices.

If it’s a bug, do it ASAP, if it’s a new feature, take your time.

And if you work for a company that does not respect developer work, you may have not choice but to do it fast and sacrifice on quality.

I’ve worked for a number of companies that would just go from project to project, and do everything fast. Ultimately, they had little success in every project because the implementation (not just the programming) was rushed through.

The best companies out there understand that good software takes time and craftsmanship.

When in emergency create the patching solution. Create a new bug in bug tracking mentioning this. Make it right, whenever you have apt time.

I think I do what everybody who is stuck working in this industry does. I get it done as fast as I can and if I have to leave out some of the nice things that would help prevent problems in the future, or make problem-solving easier in the future, I do. It is not an optimal situation but when you are stuck with deadlines based on estimates based on estimates, based on a lot of unknown variables, it is pretty much the best you can do.

Here’s a good plan:

1. Make your do-it-right plan take exactly same amount of time than do-it-asap.
2. Optimize your time to do it until your environment is happy; keep the quality
3. ???
4. Success

I do most things the routine way, the first way that comes to mind. That is quick, and I like to think that I am a decent programmer and I do most things reasonably OK on the first try.

Every now and then (I’d like to say twice per day, but twice per week is more realistic), especially when I find something extremely boring to do in the routine way, I think “what would be an AWESOME way to do this?” and I spend the extra time to find or invent a better way to do it.

If I keep doing that often enough my routine coding will continue to improve, I think.

Software is weird stuff and the software development process is weirder.

Unlike most things in real life, but like most things to do with computers

Faster is more reliable

This goes against every intuition that you life so far has taught you, highly tuned cars break down more often than standard ones, quickly built houses fall apart more quickly, homework done in the back of the school bus does not get high marks.

But slow methodical procedures don’t produce better software. Guys who spend weeks churning out requirements documents, and days on class diagrams before writing code do not produce better software. The guy who gets the basic requirement, clarifies a few issues, scribbles a class diagram on the whiteboard and gets his team coding will nearly always produce more reliable and better software, and, do so in days rather than months.

The job is not right for you.

Low quality code written “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” is a symptom of a poorly managed company.

If you are willing to take pride in your work and write high quality code, then the best thing to do is find an employer who understands that and will pay you to do it.