Our current product sucks. The code is so embarrassing I wouldn’t show it my own mother – even she would know it sucks and never wash my laundry for me again. It’s hard to maintain, hell it’s hard to even look at. We can’t easily change it and we don’t have the confidence to try. The average number of knock-on effects for the simplest of changes takes two or more digits to represent.

Of course, it’s not our fault. It’s important, you understand, that this is the fault of the language we developed the product in. The now ancient language had absolutely no support for multiple inheritance and severely limited what we could do with it. The reason we have so many knock-on effects when making a change is that the language doesn’t even support garbage collection and we often have threading issues because there’s no native thread synchronisation features in this blast-from-the-past language. Not like these shiny new languages [insert current trend here], which support GC, better threading and look so beautiful you’d have its children right now if you could.

But, in spite of this, we’re excited. We’re excited because we’ve made the decision to completely rewrite the old system using the new language. The new language is awesome, and we know that native UTF-8 support is going to help, not to mention the support for multiple inheritance, hybrid-functional semantics and it still has all the things we know and love, such as goto statements and copy constructors.

As of yet, we have no specifications or formal plans. We’d like to get some more details of exactly how we plan to architect the new system, but we’re really rushed for time. As we said though, the new language is going to make a huge difference and we’re confident that once we start work all the bits will fit together nicely. It’ll be extensible, beautiful and envied by our competitors within a few short months.

This is the number one mistake software companies can make. They believe that the shortfalls of their product are related to the fact it was written 5 years ago, and therefore must have been written in an insufficient language. They believe that the language is the problem and that the product has simply aged. It has arthritis and breathing difficulties – but we expect that, it’s old, right?

While trends do change and technology does become dated over time, a stable and well architected system does not progressively become worse just because it was written in what is now a dated language. A system does not become less stable over time because the programming language is old. The programming language or target platform has close to nothing to do with the quality of your product.

So, I’m taking this opportunity to define a new software law. I’ve always wanted to make a law and I believe I have one that applies to this situation. Henceforth, Rue’s Law states:

The holistic quality of a system or product is directly proportional to the degree by which all people involved with the creation of the system or product care about quality.

The key here is people. It’s nothing to do with how well your programming language deals with this or that, or how old the platform that your product is targeted for is. It's about how much the people involved with the project care about it being a quality product. By quality product, I mean a product that is stable, robust, maintainable, beautiful and every other adjective you require that means it is the best it can be.

Software companies need to understand that the reason their product has intermittent crashes and is insanely difficult to extend and maintain is because it has been written poorly. This could have happened for various reasons. Perhaps management create ridiculous deadlines and pressure designers, developers and testers to rush their work and prevent a proper job from being done. Perhaps the developers are inexperienced and write poor code with lots of edge cases that cause frequent bugs. Perhaps the system was never properly designed and evolved through a series of repeated hack-jobs.

For a project to succeed, it’s essential to have the right people with the right attitudes. Stop thinking that your rewrite is going to be anything but exactly the same as your existing product unless you can identify the people that made it poor and have eradicated the attitudes that caused it to evolve into the mess it is in right now.