Do software developers who choose not to put code optimization, standards and best practices as a top priority, create more useful code than those developers who want to worry about optimization, implementation of coding standards and practices above completing tasks on time?

How do these differing methodologies compare when it comes to individual performance reviews?

How do these styles compare in peer reviews?

What is the best way to influence your team to implement more best practices during the SDLC?

  • 2
    @Haylem - I think the original edit I made was better. If the title is the same as the first sentence, then what is the point of the title?
    – BlackJack
    Aug 19, 2011 at 15:46
  • 1
    @BlackJack I brought back your title and refined the question a little more. I think the three of us got caught up stomping over the same post in the edit history. Should be good now.
    – Thomas Owens
    Aug 19, 2011 at 15:51
  • 4
    SE is not a place for rants about your boss. We all have bosses and most of us have someone in the chain of command who they think doesnt belong there (Not me I think they are great /suckup off). Ranting about them here does no good. Aug 19, 2011 at 15:53
  • 1
    @Chad: While I agree with everything you said, I'm not entirely sure the OP meant to bitch about his boss (directly).
    – haylem
    Aug 19, 2011 at 16:40
  • 2
    @Chad: I've read that, and while I can understand your reaction, Jitendra doesn't say that all he did was fixing people's code. But I'd agree with your argumentation - and some other answers - that delivering functionalities first might be of bigger importance than an unfinished product with perfect quality. No one will have to maintain a product that will never see the light because it was killed early or failed still-born.
    – haylem
    Aug 19, 2011 at 22:35

15 Answers 15


No, they'll only get respect from the project's owner of the moment.

They'll get trashed for years by:

  • future maintainers,
  • future testers,
  • future project owners,
  • future managers,
  • and pretty much anyone involved with the codebase in the future.

They might even get the same treatment from:

  • the current testers,
  • the current technical documentation writers.
  • @Ivan: Thanks. Long-term thinking always wins.
    – haylem
    Aug 19, 2011 at 16:41
  • @haylem - I agree with you because people are changing the jobs quickly. so better code will be useful for new joiners to understnad the code quickly Aug 19, 2011 at 16:44
  • All true, but because of their performance they'll be long elevated away from those peons who live the pain that was left. Sad but true!
    – anon
    Aug 21, 2011 at 23:02

False dichotomy: qualities are orthogonal.

                High Quality     Low Quality

Profitable         AWESOME       Sketchy

Unprofitable        Iffy         FIRE FIRST
  • 5
    Is Iffy better or worse than Sketchy?
    – HLGEM
    Aug 19, 2011 at 17:22
  • 2
    @HLGEM: Profitable is always better than unprofitable. Aug 21, 2011 at 16:02
  • that ignores future costs created by sketchy quality
    – user7433
    Mar 10, 2015 at 16:54
  • 1
    Assigning profitability solely on the back of the developer is an oversimplification. How about product management, deployment infrastructure? Don't they also have a role to play in profitability?
    – DavidS
    Jun 3, 2015 at 12:07
  • Does this "profit" take into account tech debt? Jun 17, 2020 at 15:58

Do I agree with developers who don't care about code optimization and practices? No.

Do they do the job they need to do? Yes.

A business is about making money, and the only way to make money is to release products. This usually means that projects have strict schedules, which means what may be the best way to do something may not be the quickest way to do something.

While I don't agree with this style of developing, it may be seen as respectable by the company if products are being released.

  • I was caring a lot about code optimization in my last job but my fellow developers were not caring but they did more projects then me and when I talked to project manager he said Client wants the project on time and he never see how the code was written Aug 19, 2011 at 15:51
  • 1
    @Jitendra - If you spend all day optimizing stuff that has already been written and get no new functionality out I would not be happy either. Unless the optimization gets you something besides being less number of lines and characters in the source code then you are not accomplishing anything. Aug 19, 2011 at 15:56
  • 3
    @Jitendra - I did not say that it didnt. And writing your code in a readable manner is great. Going around 'fixing' the look other peoples code when you have tasks of your own is not. Aug 19, 2011 at 16:11
  • 1
    @Chad -It's not about re-writing my own code or fixing other people's code it's about to write the code at very first time with proper indention for Good readability , proper comments for future developer and using best practices which makes the code re-usable and it all takes time then writing the mess code which only the original developer can understand. Good code always takes time. Aug 19, 2011 at 20:14
  • 4
    @Ivan: I've had direct experience with this mentality. It goes like this. The company starts a greenfield project. Hotshot Developer X throws stuff together as quickly as possible, using copious amounts of ctrl + c and ctrl + v. The product launches in very short order. The Company is elated with Developer X. Bug reports and feature requests come in. Developer X can't keep up and gets fired/moves on to the next job. The next 3 years of development are a revolving door of new teams of engineers who can't make any progress, and Company X loses all market advantages it once had. Feb 26, 2016 at 13:54

No, and I would find the quickest route away from said company that appreciates those vices.

  • 2
    +1 for being short, to the point, and correct. A company that doesn't care about quality standards is either stupid, ignorant or a scam. Aug 22, 2011 at 13:25

No. Best practices are best because, by definition, they help get projects done more correctly, in less time, with quicker modifcation down the road, so disregarding them is guaranteed to decrease profits. Of course, your managers might prescribe practices that they think are best, but actually are not, or they might misjudge what customers will pay for and what not - then all bets are off.

Coding standards are more tricky; it is possible to prescribe too much detail to your coders, which leads to decreased efficiency. But with experience it becomes quite easy to tell useful guidelines from anal-retentive micro-managing, so the same applies: actual best practices are always worthwhile, pseudo-best practices usually not.

Code optimization is usually not worth doing unless you have measured what your bottlenecks are, confirmed that doing an optimization is necessary and measured that your clever trick actually meets the preformance rquirement. Otherwise (which is mostly) it is not worth doing, and hence not optimal.

  • 6
    Best practices don't help get all projects done correctly in less time. They are simply things that have been observed to work well on most projects most of the time.
    – Thomas Owens
    Aug 19, 2011 at 15:52
  • 2
    Blind adherence to "best practices" or anyone else's declared best way of doing things is to the development process what cargo cult coding is to the coding process. You have to be capable of understanding what a practice means, whether or not it's actually the best thing in your situation and if not, what should replace it.
    – Blrfl
    Aug 19, 2011 at 16:20

Yes and no, which is a bit wishy washy but it's a best practise and not a perfect practise. Ideally you should follow them constantly, but there's always going to be a situation where the business wants to put it's needs before your products needs.

You'll be hated by the maintainers but loved by your boss.


Best Practices is somewhat like common sense, everyone agrees that everyone should know it until any two people start discussing it in detail. No two people completely agree on the definition and there is no logical source of truth that applies to all situations.

Are you writing the guidance system for a space satellite (you probably aren't)? Then Hell No poor quality / performing code is never acceptable in this sort of work.

Are you writing a throwaway website for a one time marketing push (you probably aren't doing this either or you wouldn't have asked the question, but it is more likely than the satellite)? Then Hell Yes, get that piece of fluff out the door through any means necessary to meet deadline, the next marketing director is probably going to do something else with a different company anyway. WHAT YOU DO IS NOT ART OR SCIENCE - GET PAID.

Everything else in between: negotiable, especially as long as the dev is on the hook for initial support.

Until the second coming of whatever holy being you prefer occurs and he/she/they/it defines development practices in a miraculous manner there is going to be significant room for debate on any project not directly responsible for life and death decisions that isn't so insignificant to be disposable.

Everything outside of life-critical labeled best practices is usually more like company policy, client spec, or personal opinion. Many of them are personal opinion that many people currently agree on, but that does not make it an immutable guide for all situations.


How much money they make for the company is debatable. If there is a level of revisiting the code in question, the maintenance costs will be rising and someone isn't going to be happy. High long term maintenance costs are more expensive than doing it properly up front.

How much respect they get is probably case specific. At some point, however, someone will notice.


No, never. IMO code optimization, best practices, actual craftsmanship are the MOST important thing to have in a codebase; without it the whole thing turns to sludge and is held together with duct tape. It's an unsustainable design. It's like ignoring a tumor because it's small and you're healthy now; sure you're healthy now but a few years down the road it becomes terminal because you ignored it for so long.

I not only do not agree with developers who don't care about these things, but I have zero respect for them to boot. A surefire way to get me to consider leaving an organization, no matter how short a time I've been there, is to be surrounded by a team wherein I am the only person (if not the only person in the entire company) who cares about proper software engineering concepts.


Not caring about these things may make the company more money in the short term, but could cost the company more money in the long term on more bug fixes and maintenance coding.

Sometimes a quick-and-dirty job may be necessary if there's a rush with competing companies to get similar products to market at the same time, but the future costs of such actions should be considered carefully.


It all depends on the customer.

A customer that likes quick and dirty (and usually cheaper) doesn't care that it will present problems in the future.

Think cabinet construction.

Some will pay, and appreciate, good quality custom built cabinets. They don't mind the extra expense of hardwood drawers and top notch hardware. They don't mind it will take an extra week or even month to build and install the things.

Many won't. Many will opt for the cheap particle board mass produced stuff you get from a big box store. They want them installed in 2 days. A small gap here and there is perfectly acceptable. They don't care that they will fall apart in 10 years.

So if your managers are praising the developer that gets it done quick and dirty then either your customers don't want high quality or the managers are lying to the customers.

Only time will tell. Do what the managers want or find another job.

  • 1
    of course software can come with support so doing both might be an option. i.e. we will be first to market with v1 despite known issue however the money we earn form this will allow us to fix issues in the future etc.
    – jk.
    Aug 20, 2011 at 9:00

A good read: http://www.joelonsoftware.com/items/2009/09/23.html

But IMHO, one mans best practices is another mans nightmare. And every non-trivial code-base will be nightmare for an outsider.

Whatever you think, don't be a jerk about it.

EDIT: I'm not defending any of the positions, depending on the task I might lean to either side.

  • Depends on the "best practice" IMO. Things like having tests (not necessarily TDD but automated tests in general), following the SOLID principles, using design patterns, using abstractions/interfaces are baseline that any competent developer should be doing. Aug 19, 2011 at 16:00
  • As much as I like tests...they aren't baseline.
    – CaffGeek
    Aug 19, 2011 at 16:19

Better for the company? It depends.

For a startup with limited funds, get it done and get it out there - doesn't matter if it's messy, that can be fixed later when there are more resources.

For a mature product where there are many users relying on the quality of the software, everything should be done "properly".

Better for the individual developer? Actually it's irrelevant. Just do the same as what your colleagues are doing, and let management deal with the fallout - that isn't your job. If you're fixing other people's crap all the time you WILL be seen as slow, and you'll be the one who's still there while the others have been promoted above you. Get with the programme, or get out while you can if it's that bad.

  • "doesn't matter if it's messy, that can be fixed later when there are more resources." In theory, sure. In practice this never happens because once you push something out you're stuck maintaining it and adding new things, so you never have the resources to go back and fix it. Aug 22, 2011 at 13:24
  • I disagree. It's certainly happened on many small-medium web projects I've been involved in, and there are also many more famous instances of companies going back and refactoring their codebase in major ways - e.g. Twitter switching from Ruby to Scala, Facebook and their quest to optimise the PHP language, etc. In fact, I'm pretty sure most of the successful mature apps (web and desktop) we use every day don't have much code in common with their v1 ancestors.
    – timh
    Aug 23, 2011 at 15:04
  • Perhaps, but in six years of corporate development I've found exactly one company that was able to refactor code over time; everyplace else has never had resources to devote to "fixing what's not broke" even when the code is unmanageable. Aug 23, 2011 at 15:42

Depends on the developer and the project/situation.

Extraordinary times requires extraordinary measures.

So if I need something delivered now, and a someone is over-engineering enterprise grade java application that leverages no less than 14 of the latest buzzword frameworks while a simple python script will do the job is as worse as the developer that cuts corners and thinks buggy code will do in normal times.

Part of being a developer is being flexible. You shouldn't be slave to your tools and blindly follow practices - there will always be a case where they will fail you. Knowing when to break and bend the rules is one of the things that come with a lot of experience and are valuable.

In your case - if he delivers more value than you because speed is critical, even after factoring the increased cost of maintenance down the road then he deserves the better compensation. On the other side - if you are stuck with cleaning his mess - you have a communication problem with the management.

It is case by case basis. Except coding style - there is no excuse there.


I am sorry but I would have to disagree with most of the answers to this question, except for the top one.

The primary value of software is that it is flexible.

I don't think you should rewrite other people's code without just cause. If you have to change a module for any reason to implement your feature, you are now, for better or for worse, the owner of that module. Change it, rewrite some of it, rewrite all of it.

Never produce low quality in terms of flexibility ever. There is no such thing as throw away anything in software. If the client says its temporary and that they wont need it after a certain date, and they don't care about quality, either say "to bad" or get in writing that the code will not be altered by you or any other programmer once it is deployed to production, or you have the right to sue them.

The poorest assumption I see in some of these answers is that some clean code somehow reduces the speed of development. For any project of any substance (greater than 6 hours of work) clean code speeds development in the long term (anything greater than a week). I have seen it time and time and time again.

Poor quality code is just disrespectful to the profession and your coworkers. Sorry but true.

So no to poor quality, in terms of flexibility, ever!

  • 1
    Never say never. Entire apps get thrown in the trash. Data conversions from one system to another get used once and rot away.
    – JeffO
    Feb 26, 2016 at 15:12
  • Keeping code clean often does reduce speed of development a little bit in the short term. The important part is that unclean code causes a far greater reduction in the long term. I see a few other answers that do mention that.
    – Ixrec
    Mar 19, 2016 at 16:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.