As an engineering leader, if your focus so far has only been:

• Writing executable program in a specific period of time to meet the customer/stakeholders’ needs
• Shipping a product that isn’t faulty and works fine
• Adhering to the exact product release schedules

… well, you’re doing good from the business point of view. But there’s an important yet often neglected part of building a product that you may miss out on – the core basics of a clean code.

Some leaders tend to miss this and cause an injustice to the engineering side of the produc

Yes, how often have your team got stuck working on someone else’s messy code? Or find it very hard to build features? Or looking out for well-written documentation to guide them?

The chances are more often, and all of these events signal to embed of more technical debt to the product in the form of spaghetti code.

And that brings me to our topic,

Let’s get to see what he has to share about the topic.

Keerthi: At present, companies with legacy software products have lots of technical debt introduced to them in the form of spaghetti code. From your point of view, what are things that organizations overlook while building software?

Jana: First, I think the engineering team needs to know what the leadership prioritizes; for example, there’s a possibility of technical debt and spaghetti code seeping into the code base when there’s an aggressive release schedule or when the engineering processes like CI/CD are not articulated to them by the leadership correctly.

Second, the leadership should find a way to set engineering processes that have a lot of pardoning capability.

A lot of times, the leaders might set really high expectations in terms of telling – any code that you write should be completely automated, and then they would say, the expectation is so clear then I will not allow you to check in any code that is not fully automated from a testing standpoint.

However, developers always have challenges in terms of ensuring that they get to have fully automated test cases. Still, sometimes they would be able to come up with what I call – executable test cases, in the sense that at least it works well in their ID, Eclipse, etc.

In that case, it is not setting a good culture because, even though the demand is right and the demand is extremely high, there is no pardoning capability.

We need to allow developers to at least embrace that sort of, you know, practice, which I call extremely demanding yet forgiving engineering practice.

That is why it is crucial for leadership to take cognizance of this and then, over time, perform improvement rather than setting very high expectations right in the beginning and forcing the team to fail.

Keerthi: Your opinion: What prompts the engineering team to make the code messy?

Jana: Intentionally, nobody would want to write a messy code. From my experience, it usually happens when we have young folks on the engineering team who are either going through a learning curve or in the initial stages – where they take up some other bug fixing activity or add a new feature activity lacking clarity in terms of the technology or the framework or the product infrastructure.

You see, Software development is a continuous process.

Even though all continuous processes have great standard operating procedures, new people participating in building old stuff will break things, and it’s common.

So, I think they need some sort of mentorship or a guardian who needs to be there all the time, or at least most of the time.

And what I think is – all messy codes are not technical debt.

Engineering leadership should invest in building a code base with a lot of sophistication in terms of reliability and robustness, which will sandbox the codebase to a level where you know the messy code, will not impact business continuity, and end up not becoming costly mistakes.

Keerthi: Who’s responsible for technical debt?

Jana: I’d say the person who owns that particular piece of code is responsible, but the leadership is accountable.

Keerthi: What is behind the term “clean code”? Emphasize the benefits it can bring to product quality and business in general.

Jana: There are a few expectations I have concerning clean code:

1. Maintainability – It should be easy enough to be understood by anybody who comes into the system newly
2. Clean code is something that works in a production environment 24/7 with a very minimal set of issues.
3. Clean code always ensures – it leaves a proper audit trail when something goes wrong.
4. Anything that that code base does needs to be exposed as an API. Nothing should be massed within the code on certain property files or in some databases.
5. Clean code should have a clear representation of the business logic. Most importantly, it needs to have some sense of documentation at multiple levels.

To sum it up, if a code base is built in a way where teams need not firefight in production, do last-minute patch fixes, or press the release button behind the schedule or suffer customer dissatisfaction, then I’d call that code a clean code.

Keerthi: Please share a few tips on leaving a code cleaner than you found it.

Jana: Leslie B. Lamport, a Turing award laureate, says – If you want to do something, obviously .. we are all introspection machines and as an engineer or as a developer, if you want to solve a software engineering problem, you must write.

“Writing is nature’s way of telling us how lousy our thinking is.” ― Leslie Lamport

If you are not writing, then you are not thinking properly.

When I say writing, I’m not talking about writing code.

I’m talking about writing something before you start writing code.

Any developer, whether he writes a small feature or architects a large complex system, it is important that they complement their thought process with write-ups.

And the idea is not to make your writing specifications look like an elegant poetry. It’s about ensuring you never leave yourself unambiguous in terms of telling what you want the system to do and what you want the program to do.

Keerthi: How can the engineering leadership bring these clean code concepts together to release a flawless product?

Jana: I don’t think we’d want to maintain a clean code base and score less on technical debt for releasing a ‘flawless product.’ We do that because we want to improve ‘code agility.’

By code agility, I mean – Does the team have the ability to push features in a shorter span of time?

Would it be possible to deploy granular features in production every single day or multiple times in a single day?

As an engineering leader, one should be able to collect and derive context out of these engineering processes, code commits, or any other metric by setting up a highly sophisticated process in place or make use of platforms like GitHub to constantly review and improve code agility.

Question for you:

What are your thoughts on the subjects raised in this edition of Z to A Pulse?

Let us know your comments or suggestions below. Please “Subscribe” to receive future editions highlighting some of the most exciting topics across engineering excellence.

Thank you for reading!

Read more if interested:

1. HORUS: An engineering rule book Zuci follows for bringing together clean code concepts
2. The Mythical Man-Month: Essays on Software Engineering
3. Think and Write, with Leslie Lamport