When you’re making software in-house you can largely ship what you want, within reason. Conversely, when you’re making software for customers or clients I’m guessing you owe it to your customer, and perhaps your bottom-line, that what you produce is of the very best quality. If you don’t your customer goes somewhere else. However, the additional effort required in producing the quality software for customers can be substantial. Since you want to keep your customer, and attract new ones, you must expend the effort at a potentially large personal cost.
When you’re making software in-house there is a well-known danger of gilding the lilly. Indeed, in-house the law of diminishing returns comes into force if you spend too much time making your in-house project of the very highest quality. The law of diminishing returns can best be described as:
… in a production system with fixed and variable inputs (say factory size and labor), beyond some point, each additional unit of variable input yields less and less output. Conversely, producing one more unit of output costs more and more in variable inputs.
Since I don’t work for a software house, if I can release my code in-house when it is only partially complete, then I should be able to get a lot more stuff done for less cost.
So far so good. A problem arises, though, because I have observed that different programmers place different levels of importance on software quality. This is as probably as you’d expect, one thing we have in common is that we’re all individuals.
The sad truth is that, based on someone’s own personal standards, the bare minimum of what is required to get a job done is usually all that is done. This probably goes someway to explaining the appalling state of some of the in-house software I’ve seen, and written myself. It’s understandable because often, once the main problem has been solved the other issues like usability, maintainability, extensibility and support can be overlooked without any immediately dire consequences.
But here’s the sting, once you release something you usually have to support it too. That’s just the way in-house software works (sucks?), I guess. If you made a poor job of it then you’ll probably pay for it many many times over in support queries. In the end it seems to me that unless you quit (or are fired!) the diminishing deliverable cost turns into a potentially huge support cost. Especially if you end up layering new solutions on to an originally broken solution.
All, in all, you might as well have tried to make something a little more durable and complete at the outset. Sure you can re-factor your mistakes later, but even refactoring costs a lot more to do later than it does to get it ‘right’ at the beginning.
It seems to me that it is essentially a problem of planning. In-house software projects, big and small, aren’t usually planned properly. As a result secondary factors that would improve the overall quality are not included in any estimates. As a result of this bad planning those in-house projects are often late and buggy.
This problem is not getting any better. Years of software-development in an in-house setting have shown me that where in-house plans & design meetings exist issues of usability, maintainability and support are very minor concerns if they are concerns at all. Perhaps that should change. Just a little …