TIL: Livable Code. Living with your mess

25 Jan 2021 #todayilearned

These days, I watched a conference online by Sarah Mei (@sarahmei) titled: Livable Code. This is what livable code is.

Livable Code is the analogy that building software is like living an space inside a building instead of constructing a house or a building.

Building software isn’t like building anything else. It isn’t like planning, constructing and maintaining a tower of apartments. It’s living an space where each decision counts towards having a mess or a enjoyable place to live.

Code hoarders

We don’t end up with a messy unlivable code because of a bad choice of frameworks or technologies. Of course, the shape of the space will influence the design of our house. But, messy code comes after small decisions made every day. Patch after patch. One day you receive a package and throw the box and the plastic bags in a corner. The next thing you know is that pile almost reaches the ceiling.

Everyday Decisions and Perfect Clean Code

We have to live with every decision we have made inside our code. Instead of, building something and moving on, we live with software. We don’t have “done” projects anymore. We don’t ship software into burned CD’s and hand the maintenance to somebody else. We have to get to live with our code and make it livable for the ones around us.

There is no perfect clean code. In fact, it’s unattainable. Perfect clean code only exists on books and blog posts. The same as perfectly design minimalist spaces in magazines. We need certain amount of stuff to live. A pile of books, a video game console. An amount of stuff we can tolerate. We could have spaghetti code that nobody understands or so clean and perfectly crafted code that nobody understands either. Both extremes are unlivable.

4 rules for more livable code

The author in the conference gives 4 rules to make your code more livable.

1. Don’t make it worse. No matter what you have to do, don’t make it worse. Remind this to other team members when needed.
2. Improvement over consistency. Ship your technical debt away, one change at a time.
3. Inline everyday. Don’t have stories for big refactors. Make refactoring an everyday job. Always leave the campground cleaner than you found it.
4. Liase. Communicate, don’t lie. Treat refactoring as everything you do.
   • Don’t ask for permission. But, be upfront.
   • Don’t ask for forgiveness. But, learn every time.
   • Ask for advice. But, don’t always take it.
   • Work together. We all have to live here!

The most important part of software is not the code, or the people. It’s the system.

Happy code living!