Are software developers who ignore quality/standards better for the company? [closed]

Question

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?

Answer 1

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.

Answer 2

False dichotomy: qualities are orthogonal.

                High Quality     Low Quality

Profitable         AWESOME       Sketchy

Unprofitable        Iffy         FIRE FIRST

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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!