Leave plastic or disposable rather than solid code
This is the 12th post from my sincere dev manifesto series.
“When you don’t have the time to do things right, you have the time to do them twice”
I can work on code in one of those 2 states: plastic enough, or disposable.
Plastic code has several of these properties:
- it represents the team’s current understanding of the domain
- it is highly cohesive and barely coupled
- it is scannable
- you get its intentions
- it has a sufficient harness to detect regressions quickly
- it has clear and maintainable contracts
- it can be debugged
- you can observe what it did at runtime
- you can reproduce most use cases
These properties are subjective and debatable. Members of the same team might not have the same boundaries between maintainable and unmaintainable code. Anyway, I need to trust code enough to help it evolve and adapt to requirements to come. Then I can commit to maintaining it.
Disposable code is immutable, read only. When its requirements evolve, I can throw it away and rewrite it. Writing disposable code is a totally valid option, and I use it on a regular basis. To make sure the option works, the organization of the code must allow it. The contract linking this code to the rest of our creature must be clear and stable.
Code that is neither plastic enough or disposable is crappy code. People usually refer to it as technical debt. I also do, when the debt is taken explicitly. If the code is written in a crappy way without explicit agreement, it’s plain incompetence, negligence at best.
Only we developers can decide whether the code is plastic or disposable enough. We are responsible for the quality of our creature. The level of quality we adopt in our code base and practices is nobody’s business but ours. Like surgeons washing their hands or sterilizing tools. Quality needs to baked in every practice, including estimate. It is not extra work, but day to day work. It is not negotiable.
The practices we use to get quality code are not negotiable either. They may be different between team members, or between contexts for a single member, or between modules of the same application. For example, I might explore with a REPL and copy paste the result to disposable code in chaotic domain, and use TDD in complicated or complex domain. It depends™.
I commit to writing code that I’m confident to maintain, or to organizing it such that I can delete it without blinking.
AAAgile 
3 comments