Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

How do these differing methologies 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?

share|improve this question
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 '11 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 '11 at 15:51
2  
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. –  Chad Aug 19 '11 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 '11 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 '11 at 22:35

14 Answers 14

up vote 23 down vote accepted

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.
share|improve this answer
    
+1 for future considerations. –  Ivan Aug 19 '11 at 15:46
    
Glad to see ॐ as your avatar –  Jitendra Vyas Aug 19 '11 at 15:47
    
@Ivan: Thanks. Long-term thinking always wins. –  haylem Aug 19 '11 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 –  Jitendra Vyas Aug 19 '11 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 '11 at 23:02

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.

share|improve this answer
    
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 –  Jitendra Vyas Aug 19 '11 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. –  Chad Aug 19 '11 at 15:56
    
@chad - But that optimization can be helpful for future developers to understand the code because may be maybe a developer leave the Job in middle of Project for better opportunity. Adding good code hints, comments, code formatting to increase readability leads to good product. –  Jitendra Vyas Aug 19 '11 at 16:00
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. –  Chad Aug 19 '11 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. –  Jitendra Vyas Aug 19 '11 at 20:14

False dichotomy: qualities are orthogonal.

                High Quality     Low Quality

Profitable         AWESOME       Sketchy

Unprofitable        Iffy         FIRE FIRST
share|improve this answer
4  
Is Iffy better or worse than Sketchy? –  HLGEM Aug 19 '11 at 17:22
    
@HLGEM: Profitable is always better than unprofitable. –  Donal Fellows Aug 21 '11 at 16:02

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.

share|improve this answer
5  
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 '11 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 '11 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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
1  
+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. –  Wayne M Aug 22 '11 at 13:25

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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 '11 at 9:00

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.

share|improve this answer

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.

share|improve this answer
    
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. –  Wayne M Aug 19 '11 at 16:00
    
As much as I like tests...they aren't baseline. –  CaffGeek Aug 19 '11 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.

share|improve this answer
    
"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. –  Wayne M Aug 22 '11 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 '11 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. –  Wayne M Aug 23 '11 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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