Writing code the right way

Some recent enterprise requests triggered some thoughts for me. We were discussing revamping some of their legacy platforms, ways to do it, good practices, resources and budgets. This was a typical client-vendor pre-sales conversation but it had a lot of "juice".

There is a lot of legacy code out there and a lot of bad written code at the same time.

Old procedural good on large scale solutions is particularly under the screen radar. It's buggy. It's clogged. It's ugly.

Mid level management does agree the code needs to be cleaned up for easier on-boarding, more reliability and greater re-usability but they have a hard time to make a business case out of it. Senior Management apparently does not want to hear about refactoring and not adding functionality.

In reality the bigger your projects and the larger your teams, the more need for well written, object oriented, standardized code.

Why is that? Very simple: it's very expensive to maintain and grow bad code. I would like to say that again: *very* expensive. You can easily have dozens of developers reading bad written code for weeks and trying to sort through before they can even start to add one line of extra code: run the numbers at the average industry standards programmers wages.

If you have code sitting on servers for more than a decade and even if that is your cash cow legacy product, here are five other good reasons to tackle a code overhaul with OOP, in-line comments, standard modules/components and all that good stuff.

1. Bad code is buggy

My experience as a programmer is that almost every time when I bumped to bad written code, the programmer who wrote that code had business and algorithmic issues as well. Hence many times bad written code had defects and un-predictable behavior in different circumstances. I've seen a lot of code crashing, core dumping, displaying funny things on the output etc.

2. Bad code is hard to read, modify and expand

In enterprise environments I've seen developers spending weeks and even month reading through legacy code before they could become productive. Cumbersome, repeated functions and procedures, mysterious global variables with exotic or overly cryptic names, "cookie-cutting" web layouts, overly embedded statements are examples of bad coding practices that make a programmer's life hard.

Modifying and expanding bad written code is time consuming as well. Instead of instantiating a well written object as many times as you want, you will need to procedurally work with that function and make sure it's behaving the right way.

3. Bad code is slow

Un-optimized, higher-than-necessary complexity code is many time triggering long loops that eat up processor's horse power. And they inevitably have an impact on the performance of the solution. And no: adding more hardware is not the way to fix this. The way to fix it is to write code right.

4. Bad code is hard to support

Your tech support team will tell you the same thing. They have a hard time in front of the customer supporting bad written code. Inefficient code automatically inserts longer support cycles, more time spent with the customer on the phone and more time finding work around solutions. There is also a human component to it: many times there are disagreements between the tech support team and the software development team and you do not want to fuel support's rants.

5. Bad code is hard to document and train customers on

Your training and documentation team will tell you the same thing. They have a hard time training the customers on bad written code and an even harder time documenting a user interface that is cumbersome or some mysterious functionality. Reputation of the whole company is at stake.

So if you are a reputable software development organization start implementing standards, frameworks and OOP today.

Make it a great day!

Adrian Corbuleanu
Miami Beach, FL
http://wittywebnow.com