Every once and awhile I get to review other people’s code. One year it was 1.4 million lines of PERL code running a SaaS website developed in the late 1990s. There was another time that I ended the relationship with a BI vendor because the platform required several hundred lines of code to produce a very basic bar chart. I once reviewed a homegrown ERP developed with tens of thousands (and likely hundreds) as Oracle stored procedures. My absolute favorite was reviewing several dozen revenue driving applications built on top of Microsoft Access which led me to write the post asking (begging) friends to please stop creating them.

There comes a point where the terms “technical debt” and “legacy” don’t do justice for code nightmares. 

When there’s hundreds of thousands of lines of code – developed on any platform or language – that doesn’t leverage frameworks, design patterns, logging, exception handling, code commenting and other software development principles. When there aren’t architects setting standards, pair programming practices in place, or coder reviews instituted. When designers decide to mix business logic with presentations or when database developers elect to develop stored procedures to do everything.  When copy/paste is considered code reuse and when obsolete code is never removed from the repository. When there isn’t a version control repository because this was supposed to be a small application.

I could go on…

Mind you I don’t blame all of this on the developers that created the mess. Some didn’t know better. Others weren’t given the right platforms for the job at hand. Likely all of them were under time pressure to get thing done the best way they could.

Management is to blame for poor coding practices

Here’s the real problem. Many organizations are doing a ton more coding today than they were a decade ago.

You aren’t just building brochure-ware websites, you’re building multi-device user experiences that connect with transactions and data from multiple enterprise systems. You’re not just developing reports, you’re instituting automation, dashboards, and other analytics that drive decision making. Many of you are developing APIs and microservices just like software companies.

All of you are under time pressure. Pressure to go beyond the MVP. Performance requirements. Regulatory requirements. Increased security and testing requirements.

What are you doing better today to develop quality software?

Today it’s so much easier to write more and more code. You can get development environments with a credit card and a few clicks. You can search github and leverage one of the very many coding frameworks or open source libraries out there to ease development. Or you can use a lowcode platform.

There’s demand for more applications and it’s easy today to have applications with lots of code – whether you wrote it or just included it. My question is, what practices are you putting in to ensure your codebase is maintainable?

What your development practice requires

Here is my short list. Your development team needs a person responsible to be an architect who not only defines development standards, but finds ways to review and measure them periodically. Your development leads should be reporting technical debt at the end of every sprint and you should be prioritizing a sizable percent (I recommend 30%) of your velocity to address it.

Your development team should be estimating their agile stories, ideally in story points so that the complexity of the business requirements is reported back to product owners.

If you have developers that are lazy about documenting their code or implementing exception handling, logging, and unit testing then this needs to be addressed.

By the way, it’s not just coding itself that can create problems. Watch out for bad behaviors from product owner and from technologists.

You need a QA practice and they need to be automating their tests.

You should be listening to your developers and they should be recommending tools, libraries, and frameworks, and services to implement the applications. But the key word here is recommending. Developers shouldn’t have carte blanche to leverage any open source repo or integrate any cloud service they want based on their own expertise.

And you should be developing many more POCs before making the decision to leverage a new technology.

Lastly, if you’re a CIO or a CDO and have never coded before, make sure you have one or more lieutenants who have this experience. You can always call me for help.

End rant.