Do You Want to Stay Productive?

Ralf Westphal

What’s the question to which clean code development is the answer? I think it is: Do you want to stay productive? I mean, indefinitely. I mean, being productive in a sustainable way.

That means, clean code development is not the answer to questions regarding runtime efficiency like scalability or performance or security or usability. Look to distribution in conjunction with clustering or asynchronous/concurrent programming or encryption or GUIs or task oriented user interfaces for that.

And it’s also not the answer to questions regarding short term productivity gains. Look to keyboard shortcuts or the latest frameworks and language features for that.

And it’s also not the answer to questions regarding process waste reduction and dealing with unclear requirements. Look to Lean and Agile for that.

Clean code development is about staying productive by dealing with code differently.

  • Staying productive has to do with how easy it is to test code. Why? Because without high testability (i.e. the potential to put logic under test) it’s difficult to reproduce bugs or gain understanding of code by looking at its behaviour in isolation. Low testability produces distractions from value creation.
  • Staying productive has to do with how easy it is to understand code. Why? Because if code is hard to understand then any change that’s required takes longer than necessary.
  • Staying productive has to do with how correct code is in the first place. Why? Because if code is incorrect then correcting it is a distraction from value creation.
  • Staying productive has to do with how easy it is to distribute work on a code base among team members. Why? Because if team members have to wait for each other or keep stepping on each other’s feet or even inadvertently destroy each other’s work, then the speed of a team is lower than possible.

To be perfectly clear: fixing bugs to me does not classify as productive work. It’s a deviation from what produces value. It’s a hesitation with regard to progress. It’s a repetition of what should have been done correctly the first time.

And also note: clean code development is not about SOLID or Object-Orientation or Function Programming or any paradigm, pattern, practice or principle you’re fond of. They are all just means which might help. They are not an end in themselves. Avoid cargo cult by focussing too much on them! It’s always and only the purpose that counts. If someone comes up with a not-so-SOLID way of coding but testability or understandability increases, then follow that path.

Here are some checks you can do to see how productivity evolves on your code base:

  • Check how long it takes to bring features from „ToDo“ to „Done“.
  • Check the ratio between time spend on bug fixing vs. adding new features.
  • Check the ratio between time spend on understanding what code is actually doing vs adding new features.
  • Check the ration between time spend refactoring code vs adding new features.

(Please note: Refactoring by definition is not adding new features. It’s neutral with regard to any runtime requirement.)

If you find it difficult to measure the above, then maybe you want to work on your process first. It seems to lack the basic attributes of systematic work.

I’m not saying software could be developed without spending any time on bug fixing, understanding code, or refactoring. My point is, that these activities do not produce any value by themselves. They are necessary and unavoidable evils and will always exist to some extent.

That’s where clean code development comes in. Clean code development means to fight these evils every day wherever they raise their heads.

Since software delivers value through its code, the ultimate goal is a code base free of impediments for the addition of new features.

However, that does not mean, clean code development just looks at code. It’s not content with the right amount of comments or longer variable names or shorter functions or even high test coverage.

Clean code development starts before any code is written!

Clean code development starts with a plan, a design. Because understanding code and testing code has to do with the basic layout of code. Its granularity, its abstractions, its dependencies. Clean code is about structure and anatomy. And to get that right for a set of requirements is a matter of „thinking before coding“. It’s a highly creative activity. That’s where conceptual problem solving with regard to the domain really happens. And whatever the blueprint is that comes out of this software development phase it’s a framework for any code written. It’s the foundation of how clean or dirty a code base is right from the start.

And before the plan there needs to be understanding. Clean code development thus really starts even before the design phase. It starts by working with the customer (or her representative) to find out what the scope is and how the behaviour of the code really is supposed to look like. Clean code development first really has to narrow down requirements to clear cut interactions between users and the code base. Only then design has a specific starting for its problem solving and blueprint production.

Code is the ultimate artefact of clean code development. And, sure, code needs to have a certain form to count as clean. But this form does not appear out of nothing while hacking away on a keyboard. It’s in large parts just a manifestation of what design has come up with on the basis of a systematic analysis.

Clean code development is not a practice for nerds sitting in a basement churning out code. It’s a comprehensive and systematic approach requiring „the full developer“.

I’m tempted to redefine „full stack developer“ (FSD) like this:

Full stack developer: A developer trained in systematically working through analysis, design, and coding to achieve lasting productivity on a code base.

Stack is a fitting image here, I think, because clean code is resting on a clean design which is resting on a clean analysis. Clean code development is working its way from bottom to top through a stack of phases.

Of course this does not imply that should be done just once. Right to the contrary! It can and should of course be done iteratively and incrementally. It can be done every day, even multiple times per hour. The turn-around time from analysis to release of code depends on a lot of parameters. But that’s all orthogonal to what clean code development is about: phases directed at the production of code so that productivity stays high.

[maxbutton id="2"]