Why is short project lifetime and other situation-specific reasons used to excuse crappy code?

Question

Every now and then (including on SO) people say things implying that "if the project is short lived you can leave obvious defects there" or "that memory leak only accounts for 100 bytes per whole program lifetime and could be left".

Now in my practice I always reuse company-owned code to the greatest extent I can. Like if I need something and I can find it in the company codebase I take it from there and reuse or adapt. This means that any crappy code will be reused as well and I might notice or not notice defects therein. So the defect in some "test we only need for a month" can slip into a proram we ship to customers. And a leak that "only accounted for 100 bytes per lifetime" now could account for 100 bytes 10 times per second in a server application intended to run for months.

That's why I don't understand why excuses like that are offered. Is our compamy the only one having a source control? Or are we the only company that requires writing human-readable code?

Could anyone shed a light on why people seriously offer such excuses?

Answer 1

Because it's generally easier and faster to write bad* code rather than good** code. If the project is short-lived, then often there may not be enough time to write the whole thing 'properly'. Humans in general can be pretty lazy sometimes so if it seems like it's a single use project then why not take the shortcuts that make life easier in the short term?

*hacky, inelegant, uncommented, copy+pasted lines with minor changes, works only in the circumstance it was intended to be used for

**clean, usefully commented, well tested, extendable and reusable in the future

Answer 2

It's a delicate balance between perfectionism and shipping the project. "Shipping is a feature"- the best written code in the world doesn't do any good if it never ships. A quality team will find the right balance naturally by trial and error.

Answer 3

Joel Spolsky on bug fixing - Hard-assed Bug Fixin':

As a software developer, fixing bugs is a good thing. Right? Isn't it always a good thing?

No!

Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.

In addition, consider YAGNI - when you find a bug or write hacky code, document it. Only when you need reuse this code you really have to fix it.

Answer 4

Often software is developed against huge business or market pressures to ship, so technical debt is incurred just to get it out the door in time. The key is to recognise when this has happened, and allocate suitable time to refactor a codebase if the product is to evolve past this stage and still be maintainable in the long term.

Answer 5

It seems that the code was not a problem until you decided to reuse it, therefore you should have the responsibility of fixing it.

Ideally all bugs would be fixed when found (especially if there is a lot of code reuse in the company), but if resources do not permit then it's reasonable to leave them as is.

Answer 6

Because sometimes things genuinely are short-lived. If something's going to be re-used, engineer it properly. If something's only needed for a short, specific purpose, then make it quickly so people can just start using it.

If something you built quickly turns out to be needed long term, then rewrite it.

Recently in England there was some pretty bad flooding, and the army was sent to rebuild some bridges across rivers where the bridges had collapsed. One of the soldiers in charge of the project commented that they were used to building bridges across rivers for tanks to cross, so this job (building a small foot bridge across a river) was somewhat easier. They got it done very quickly, because they were engineering for the requirements of the project, not worrying about whether their bridge could withstand tanks crossing it (not often something bridges in the Lake District need to be able to withstand).

Answer 7

They offer such excuses because they are valid a lot of times. It makes no sense to ask from a CRUD page from a app used only by one costumer to have the same quality as the space shuttle trajectory calculator. Want it or not, software quality has a price (harder an longer testing, more competent and well trained professionals which cost more, etc). Any sensible person would evaluate the costs vs the gains of any strategy rather than just strive for the unattainable and mythical perfect software.

As to your point about reuse, it only makes sense when thought from start, i.e. it costs a lot more to write reusable software so you either have to expend that upfront (and management has to have a little brain to do that), or live with the one-offs. Write crappy software and then blindly reusing it is a poor decision. Looking at it and getting ideas for what to not (and what not to) is still a good idea though.

Answer 8

That 100 byte leak could end up losing 1000 bytes a second, but alternatively it might take up a significant amount of development time that could have given customers working functionality that they need. We (nearly) all aspire to perfect well written code, but the customers aren't interested in that, they want functionality they can use. Most of the time well written code provides reliability they need, and badly written code causes confusion and delay, but sometimes it does not. Sometimes customers need something that does most of what they want now, and not have to wait for improvements they may never or rarely see.

See Version 1 Sucks, But Ship It Anyway for one take on why crappy code out there can be better than clean and perfect code in house

Answer 9

Because people make genuine mistakes.

Is our compamy the only one having a source control