Completely Rotten Administrative Program

A far-too-common story:

In general, I think that there is no useful tradeoff to be made between quality and the other dimensions, time/cost/featues.

What do I mean by "no useful tradeoff"? I mean that given the range of customer tolerance, we cannot generally save time or add more features by reducing quality but keeping it inside that range.

In general, I agree fully. In fact, I was greatly surprised, several years ago, to find myself in a situation where I was explicitly required to deliver a low quality, bug-ridden system despite my desire to do otherwise.

One of my assignments, many moons ago, was to upgrade a system called CompletelyRottenAdministrativeProgram (CRAP) [1]. CRAP had been written several years before by developers who had since left the company, and had received very little in the way of maintenance ever since. Certain library calls had to be changed, and there was a very hard and fast deadline after which the old library would not be available, so the CRAP system *had* to be updated, and I got bagged with the task.

Once I started looking at the program, I realized that CRAP was truly bad. There were at least three distinct "coding standards" (depending on which VB3 form you were on), gobs and gobs of duplicated routines (often with the same bug copied and pasted multiple times; see CloneAndModifyProgramming), several places where the users warned me "click here and the app crashes", etc., etc., - and of course, nothing in the way of automated tests, manual tests, documentation, or anything else.

I came up with an initial estimate of how long it would take to get the code up to what I felt was a decent quality standard - at least to the point where the app didn't crash if you clicked the wrong button - along with the library upgrades. My boss and the business owner both said that the estimate was unacceptably high, and wanted an estimate for just the library upgrades. I scratched my head a few times, did some more estimating, and came up with a number - which they accepted. So I ended up delivering a new version of CRAP which was bug-compatible with the previous version - but that wouldn't have any *new* bugs due to the library changes.

Effectively, I shipped sh1t. In one sense, it was even lower quality than before - the code I added followed a *fourth* coding standard, albeit one that actually made sense - and it certainly had all the old bugs left in. But it was what the customer explicitly asked for, after the costs had been pointed out.

What are some examples where there is a useful tradeoff?

I didn't think trading quality for time and money was a good idea, but I didn't get to make that decision. The business owner chose to stick with a bug-ridden system that would continue to work past the library cutover date, rather than get charged more for the same functionality with more bugs taken out. She made the call, and as far as I know remains satisfied with it.

It may or may not be significant, though, that this was a "BrownFields?" type of project - the application had been built, and had been in production for years, before I came on the scene. It likely would have been cheaper in the long run had the app been built (and maintained) to high standards in the first place.

[1] The names, acronyms, genders, business problems, etc. have been changed to protect the guilty. But, great Ghu, that thing was a pile of crap :-(

-- EdmundSchweppe?

What are some examples where there is a useful tradeoff?

I've worked on countless systems where this was a useful tradeoff. I think the problem is that quality is a matter of perspective. What seems like low quality to me as a programmer because it is fails in unpredictable ways may be high quality to a business owner or investor because it makes money for them, regardless of its failures.

This is also a common result in evolution of DNA. "Good enough" reproduces now and wins. Perfection only shows up as a result of lengthy competition.

-- EricHodges