Frustrated With Programmers Writing Low Quality Code? Don’t Hate the Player, Raise the Game!

May 3, 2020 By iwano@_84 Off

Improve Code or Improve Software Developers

How often do you hear complaints about bad code? In amongst the banter is always a view that the system must be re-written. Much of that banter is about how to re-write things better this time. How to re-design the database schema. How to improve the software by stealth during the implementation of a business requirement.

Amongst the “improving” or “re-writing” banter, very little, practically nothing, is said about the coders themselves. The same teams that have gotten the software into a legacy state, want the chance to rewrite it all. To do it all properly this time round.

Insanity. Doing the Same Thing and Expecting Different Results

When programmers moan about the software quality and want to re-write it, You can’t help but wonder what has changed. Ask them, and the reply will be that they were not given enough time to code properly. That they were too busy fire fighting to write software the way it should be written.

So the business hasn’t changed. The pressures haven’t changed. The developers haven’t changed. Your sanity is being tested! Is it feasible to do the same things and expect different results?

Solutions to Legacy Issues

Are we missing a trick? Shouldn’t we just fire the developers at fault. And outsource or off-shore the development of a new system. Or revamp the process framework.

Also how about slapping some controls in place to limit the number of afferent and efferent couplings that a unit of code can have. Perhaps place restrictions on the cyclomatic complexity, or the dependency relationships allowed.

Why aren’t your developers raising their game?

Sure, give the above proposals unremitting consideration. Feel free to fire those, not pulling enough weight. In this essay we focus on the software developers that you have. We want to know why, despite your best efforts, the quality of their code, is at best, pithy.

The Road to Improved Application Design

There are other methods of improving the quality of software a team writes. This article makes a bold, although not wholly surprising, assertion. That “the road to software salvationHome Grown Talent!

Growing Technical Talent

Your low quality software, despite the excuses, cannot be anything but an affirmation that you have failed to grow your software developers up to a standard necessary and sufficient for writing enterprise class software.

We dig a little further, to uncover why this skills gap unleashes a plague of locusts that relentlessly eat away at any discernible vestiges of quality software.

More specifically, we will examine the current set of code styles and methodologies, and while doing so, pay particular attention to how much expertise, most of the world’s software developers really have. Also how much of this expertise is put to task exploiting and deploying best practice software solutions.

Wheeling Out “Industry” Phrases

Up until now, in interview rooms, IT books, and tech dinner parties, software professionals clock up many speech cycles which in turn bandy about, their favorite code styles. They discuss the best approaches to writing code. When in full flow, you can catch them wheeling out “industry” phrases and acronyms like

object / aspect orientation, Gang of Four (GoF), Top Down

Test Driven (TDD), Model Driven (MDD), Use Case Driven

Xtreme, Lean, S.O.A, Restful & Inversion of Control (IoC)

Tops Down, Bottoms Up, (Oopsie), N Layer ArchitecturesThe Munitions of a Coder

There is no doubt that the above code styles are just a few of many right approaches to writing good quality software. The question is whether developers have these styles and strategies to hand as armaments in their munitions arsenal.

Blasting away Cannon Fodder Examples

It is self-evident, judging by the extremely high proportion of poor quality software within enterprise applications, that computer programmers by and large do not have the aforementioned techniques in their weapons arsenal.

We assert that the typical software developer, only sees these code styles, these “programmer weapons”, in use blasting away cannon fodder examples.

Flicking through a (fictional) Weapons Today Rag

What is actually going on, is akin to flicking through a copy of a “Weapons Today” (fictional) magazine, then settling on a particular weapon. Still reading the magazine, our hypothetical hero nods, in affirmation of his understanding of the weapon’s power.

Our hypothetical armchair hero perhaps then views a video of the “weapon” in action against a straw bail.

From the Sublime to the Ridiculous

Onward with our analogy. Our armchair hero is still in his armchair. He now believes, after reading about the weapons capabilities, and seeing the weapon in use, that he can actually use it! That really would be going from the sublime to the ridiculous!

The real world isn’t cannon fodder. We need to move on from cannon fodder “examples” that litter the pages of How to Code Manuals into the real world. Cannon fodder is fine when you are learning. But a professional needs more.

In the World of Programming, Speed Determines the Winner

Bringing restful architectures to the software development table, is like bringing Kung-Fu to a street fight. Even those who have studied martial arts for some years, would not be so foolish, as to attempt using it for true self-defense.

The Kingdom of Application Feature Implementation

A software developer turns to what is instinctive when battling to implement a gaggle of application features. In the Kingdom of Application Feature Implementation, instinct is King.

So if you are a software team leader, an IT Manager or a CIO, do not tear out your hair in frustration that software developers, despite your best efforts, are just not able to

practice test first development and writing good quality, high coverage tests

illustrate discernible separation of concerns within the software they write

consistently reduce cyclomatic complexity and generally raise code quality

use hierarchies to reduce conditionals, or interfaces to reduce dependencyDon’t Hate the Player. Raise the Game

The lesson is this. If you want your software developers to be able to execute these styles, you will need to raise their capability maturity. Reading books, or going on a course, serves only to make them aware that “something called [acronym or name]” exists.

Schooling developers in the Abstract Factory or Inversion of Control patterns, is just the beginning. They are still a long way off being able to execute these coding styles & skills in a pressure programming situation.

Bridging the Development Skills Gap

Generous lashings of artistic license have been applied in equating Kung-Fu and street-fighting to the art of writing software. Whether you suspend your disbelief or not is neither here nor there.

The intention is that you look seriously at what you can add, to bridge the gap between a coder that has attended a one week course, and one whose code reflects the virtues espoused by the academic fraternity of software developers.