Code that leaves a legacy is the opposite of legacy code

As a freelance consultant I am strikingly amazed about the lacking code quality of many projects. The fail-fast and do-80%-of-features-in-20%-of-the-time approach has empowered a lot of ideas to be followed out with developer time. This is is good, as a lot of great ideas can emerge. On the other hand I see that many start-ups fail in one very important area: getting inexperienced personnel to be effective and productive in the long run.

From a business perspective I think it makes sense to hire well experienced and expensive developers to drive the core business software. But to maintain a business you should leave maintainance and continuous feature development to your own breed of developers. That makes sense: you get the best of both worlds, expensive genius level code and payable code and feature maintainance.

But for this to happen you must make sure that your experienced and expensive developers leave code with a legacy... not legacy code!

I am having a hard time understanding CTOs when they do not pay attention to the code quality generated in their organization. It must be both business and code features that must be developed, but most chief officers focus on business features only. Of course, that's what matters to investors, but don't be fooled, you need an organization that is able to continue to deliver business features.

If code quality suffers during the many crisises of the project you pile up so-called technical dept. This is a rather difficult term to understand in its full detail. I want you to take home this consequence:

Your team will get demoralized by legacy code

The reason for this is simple: bad code with a high technical dept makes developers feel less self-effective. Reasons:

• each "movement" within the code is cumbersome
• lacking confidence in functionality
• minimal creativity possible
• high amount of time spending to correct failures instead of creating

The consequences of a demorilized team are slow feature output, high volatility on personell and lacking cooperation within the team.

The easy way out

These negatives are avoided if you use your experienced and expensive developers, they know the code as the back of their hand or are able to learn it quickly. They do not suffer from any of these points!

That is the reason why CTOs keep their best developers on projects for too long, making them irreplaceable, imperilizing their own idea because they could be used with new features that really need their genius, or keeping the optionality of letting them go. Keeping this option is worth money.

The wise way out

Instead of focussing on business features only you should make code quality first class citizen. Make sure that your experienced developers develop their software for students! Get a couple of students to work for you and let them reflect if they feel self-effective and understand the code. Have your experienced developers form architecture meetings, have them obsess over clean code. Make them champions for zero technical dept code. Have your own breed of developers attend public code reviews held by your gurus. On top of all, maintain the highest level of mutal respect. Bad code is not a failure of your students and own breed developers, you expected that. It is the failure of your gurus!

On the wisdom of software engineering

One lesson I learned when working with clients: never give them the option for unit testing, code refactoring or architecture design. These are not optional, they are mandatory. You will not save money by skipping them. It will never happen. Dump it! The very same reasoning applies if you, as chief officer of some sort, talk with your investors.

No investor would give their money if you told them that you don't do environment simulations when building a bridge, because it is more important getting revenue off it by opening it sooner for traffic. Simulations could be done later? Not really...

Get some inspiration: https://www.youtube.com/watch?v=j-zczJXSxnw

Do you think at this moment of time we are further progressed in software engineering? I really wonder...

My Take on Legacy Code

There are many facts and tales out there about legacy code, so I will not repeat them here. Just to have everyone on the same page, I consider legacy code as code that takes a master of science in code forensics to understand: it is usually not testable, not extendable, doesn't have separation of concern architecture, also called spaghetti code, and does not adhere to the other clean code standards.

It is also important to undestand this: legacy code has nothing to do with time! Code just doesn't get old by itself. If you got the impression that this happens, then we need to go philosophical about the meaning of time. You see, as "time" goes on, so do many other processes. One process that I identify as the most significant deteriorating process is the one broadly called "business case is changing". Of course there are other processes that "deteriorate" code, but I hope you understand now why I say, it is not "time" itself.

Code that does not deteriorate will therefore never be legacy code, even if you would technically need a code forensic. "What!?" you may ask? Indeed, I am contradicting myself a bit here. But see, I am right within my own logic: there is no need for a master of science in code forensics as no one ever needs to touch that code again. I argue, you may write that code any way you want!

On the other hand: do you really know that you'll never ever have to touch that code again? I believe it is a gamble. As most gambles there is some probability given to the event that code needs to be changed as some time-dependent process made it's functionality obsolete. Please ask all your developers to go through all their projects that they ever worked on. Which ones did change and which ones didn't?

Okay, I'll share you my experience:

• All code that I have written during my studies never needed changes in functionality.
• All code that I have written in my start-up underwent severe changes
• Most code that I have written for customers as a freelancer underwent severe changes while I was working there.

Oh see! You got young bloods coming out of university having the experience that code need not be refactored! Do you understand the significance? Did I?

I learnt it the hard way: plan your code so that you can always react to changes! I will never take that gamble again.

Experience must lead to code with a legacy

It is as simple as that. Doing business and making investors happy is hard, but not taking code quality serious is throwing away experience you have in your team of developers. Taking code quality serious is building a legacy.