Does "write quality code" advice apply to companies of any scale? [duplicate]

Question

I carefully followed the "always write quality code, unless you're writing a prototype" advice during my career as freelancer and software developer. I was convinced pretty early that avoiding to do code reviews, testing, QA or refactoring doesn't make the project faster, but only slower.

Books like The Mythical Man Month by Fred Brooks or Rapid Development by Steve McConnell confirmed my thoughts. Professional experience in medium-scale companies also showed me how much money and time is wasted by not even trying to do quality work.

At the same time, I often heard my colleagues complaining that constantly maintaining good code quality or simply achieving good code quality at all is too complicated for small scale companies and small teams:

• It's just too expensive to get the people able to write and maintain quality code.

  If the company can hire either two persons for $3 000 per month or one person for $6 000 per month, most managers would consider that two persons will be more productive than one: maybe not by a factor of two, but still. Or the small company can hire one person for $3 000 per month and spend the remaining 3 000 for something else.

• There are too many aspects to take in account in order to be able to do it within a small team.

  A single person can hardly take care of the style of code, readability, architecture, design, ease of testing, testing itself, reliability, security, ease of use, performance, etc.

• And it doesn't worth it.

  It's not like a piece of code will remain in the code base for the next fifteen years and will be read thousands of times by hundreds of developers. Chances are, the same person will maintain this piece of software for the next five years, then just throw it away and write a better one from scratch.

I usually reply that one should remember the productivity factor of 1:10 among developers and that most of the time is spent not writing code, but maintaining it. This means that low quality code is still ways more expensive.

But is it so?

Should every company, no matter its scale, try to hire the best possible developers they can afford, and encourage them to write quality code, or there is scale above which code quality becomes just a burden, a waste of time and money?

Answer 1

Well, this is a big question that is perhaps too big for the site. But let's focus on some of the core points.

Is quality worth it?

This stackexchange question goes into some of the details about the cost of bugs depending on when they're found. Long story short, bugs tend to cost an order of magnitude more to fix each time they move from development to QA to customer validation to the field. Spending a dollar to fix a bug during programming saves you a thousand dollars that it would take to fix the bug in the field.

In that regard, it is always worth it. High quality code costs less to make than low quality code to make and then fix later.

Assuming you intend to fix the bugs. The level of quality needed for a nuclear reactor is different than the level of quality needed for your Angry Birds clone. Having too much quality here can be a burden and diminishing returns of course. But if you intend tho fix the bugs, they pretty much always cost less to fix during development.

Should we hire the best developers?

Probably not. The usual "cost savings" of good developers comes from two places:

1. Fewer bugs - see above. The fewer bugs produced by development is cost savings for the company.
2. Awesome Features - the top tier developers can do awesome things that "average" developers simply can't. Google wouldn't be google without making a search engine leaps ahead of others at the time.

The problem comes that most programming jobs aren't with technology companies. They're making vanilla websites or doing data plumbing from one point to another. Merely average developers are perfectly capable of implementing that.

Fewer bugs is a bit of a relative issue too. A 99th percentile developer may catch all the bugs, but if you're doing pretty simple work, then a 75th percentile developer may catch all the bugs at half the cost.

In that regard, it's not always worth it.

Small teams just can't make quality software.

Small teams can't make quality software only when you won't sacrifice scope or schedule. There's three levers for software management: cost, scope and schedule. If your costs need to be small and you want high quality, then you need more time or you need fewer features. If your company wants to sacrifice quality for more features or a quicker schedule... That's their choice, but there's nothing forcing small teams to make bad code.

Is that choice reasonable in some scenarios? Sure. I've seen scenarios in a startup environment where time to market is so important/valuable that it makes sense to cut corners now. In many startup cases, being the first to market is of almost infinite worth. The great idea gets associated with your company and the second entry to the market has no chance since everyone wants the sexy new thing - not the copy.

So in summary, it's probably not always worth it to hire top tier developers and make high quality software. Sometimes low quality software now is more valuable. And hiring average developers will be a more cost effective way to produce "good enough" software depending on the relative cost and productivity of those developers. But I would argue that for most scenarios, quality software (and by extension, good developers) are the most cost effective way to do business.

Answer 2

I think they should try and get the best, but what is best in some situations doesn't apply to others. It depends on the management of the company/development team, but companies of different sizes can typically have these issues for different reasons. In the book, "Dreaming in Code", their project had talent, time, money and a desire to create something great, but they may have been better off with one pretty-good programmer instead of the pack of 10x developers that managed to create a big mess that took forever.

Prototype - If you would get the requirements from the business side of a startup, it would probably sound more like a prototype, but try to convince a developer of that when you release it into the wild. That doesn't mean it won't benefit from a 10x programmer. I think one of the biggest factors in that "10:1" development ratio, is the ability to build things lesser programmers just can't do (1000:1 ?). Many large companies have startup like projects and can suffer the same fate.

Good Enough to Say "No" Good programmers are in a better position to refuse to write bad code. They've experienced the negative consequences first hand and are better at persuading the powers that be, but I don't care how good you are, if the business pushes enough, you'll write crap. Arbitrary deadlines are why there is enough time to do it over instead of doing it "correctly" the first time. Larger companies have plenty of managers who have nothing better to do than to keep asking when things are going to be finished.

Best Practice Habits Good programmers develop fluency and good habits because they study, take the time to learn, but most of all believe in them. They don't waste time pissing and moaning about: tests, documentation, source control, bug tracking, code reviews and standards. They know how this makes your job easier. They may not know a lot of languages, but that's not because they refuse to use them. There's a difference. Thousands of developers are able to be productive with Git, what makes you so special? Large companies can hire developers of many levels and should be creating an apprentice program, but just because you write 10x code doesn't mean you have the ability to leverage your talent and teach others.

Hiring

1. Attracting Talent - Many positions are just unattractive to good programmers. Part of it is salary, but also consider the rest of this list. Some like stable companies, others want a startup. Tech companies are usually more attractive than those in other sectors.
2. Ability to recognize talent. Good programmers want to work with other good programmers or at least potentially good programmers. A company may make one lucky find, but rarely can they build a complete team. Larger companies will build HR staffs that are good at hiring core talent (non-technical), but have no insight to hiring programmers. They sometimes rely on recruiters.
3. Keeping Talent - Why hire top developers if they have no control? Who is making these so called better decisions? Creative people struggle on the assembly line. Don't lie and tell them a new feature is needed immediately to close the next sale when in fact, it's just a nice to have. Talent will eventually leave. Non-technical/creative companies struggle because they try to make the programmers work like everyone else.
4. Recognizing Good Code - Most of the code written is never been seen by anyone else who writes code. Clients want results. Sometimes you can convince them a new feature is going to be difficult because of the drastic change in requirements, when in fact, the code is poorly designed.

Most companies will settle for lesser talent because they just have all this other baggage that is required instead of the skills needed to do the job. "We don't want someone who just sits in the corner and writes code." A lot of developers don't shine on the "Tell me about yourself." question, but just love to talk about the things they build. I saw a guy sit very quietly at a dinner party, but when he started showing the host how to stretch the screen size to use up all the space on the monitor, I thought he was in sales. He was even able to do it in a black t-shirt - The Horror.

Answer 3

The problem with many companies is that they are less interested in having people write quality code than having people write "good enough quality code," e.g. code that just barely does the job. In this context, having two people to check each other's work seems like a safer bet than hiring one.

In order to get people to choose you, you need to persuade clients that 1) only high quality code will do the job and 2) you are a provider of such high quality code. The second is perhaps an easier "sell" than the first. If you happen to be a subfield where "anyone" can write "adequate" code, that might be tough luck for you. Then you'd need to find a new area where the minimum standard is higher and demands your level of skill.

Answer 4

The code quality is not about if it worths or not, it's a way of doing things. The quality code always worth it.

If a company don't care about it, this give you a key indicator that it's not a good software development company, it's simply one more software company. Good companies try to refactor every piece of code that is not very mantainable or architectured.

You'll never write the perfect code, but as we do in every aspect of our lifes, you need recheck it, refactor it and use some tools to help you following best practices.