Code is constraint

Last week I watched Michael Feathers presentation: Code blindness.This is a great presentation, and it inspired me to think deeper.

Before I think code is important from the programmer's perspective: craftsmanship, and professionalism. But it seems quite far to the managers. They don't know understand it and don't know how to connect this with their daily management.

Today I would try to think from manager's perspective: borrowing the idea from theory of constraints, I will say code is just another constraint, like other constraints manager usually considering: time, budget, people. More specifically code quality will impact developers productivity and on time delivery.

We know that the clean code base will easier to understand, easy to make change, and easy to maintain,but bad code base will hard to understand, hard to change, and hard to maintain, which greatly slow down developer's productivity.To avoid this happens, we have to deliberately keep code lean.

There are two main metaphor to support the clean code:

• Metaphor of technical debt: code base is like technical debt, we have to pay off first by taking effort to refactoring, otherwise it will become harder and harder to change and maintain in future, so refactoring is the interest we pay for the debt.
• Metaphor of software entropy: code base is like entropy, by nature it will gradually go to messy, we have to constantly refactoring and keep our codebase clean.

So we can get the conclusion: code can be asset if it is clean; and can be debt as well if it is messy.

So far we know that code is very important to developer's productivity, it should be consider as a constraint by the manager. But I found many managers are totally unaware of this issue:
They just assume developers are all professional and their code will always good enough;
They only care the schedule, only care something get done, but does not care if the code is well maintained or not.
And since managers unaware or ignore this issue, they might make decisions to make code base even messier, for example,
- they will pressure developer to push them make quick-and-dirty fix, which cause the long term issue;
- They do not care for the code, so they measure the performance only by task been finished, not by how good the code is written, so we can imagine developer will not actively care for the code.

Code is important, but if you unaware or ignore it, then you will not manage it.
If you don't manage it, then you will finally lost the control and then we will get real problems.
When you have the problems, but you don't understand the root cause is code quality, then you probably trying to solve the issue in a wrong way.
I heard so many times from managers said something like "we need to work harder", "we should work more careful", which are totally useless slogans.

Suggestions

1. Manager should aware the code quality's importance, bring the connection between good code quality to developer's productivity and developing schedule.
2. Manager should cover code quality into their daily management, right now there are so many different tools to do code analysis and measurement.
3. Manager should create a culture to encourage software craftsmanship, clean code is a foundation of good software product,  clean code fit nicely the "build quality in" lean principle.