Clean code is simple and direct

[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]

image from Jeff Atwood’s Coding Horror blog

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

Grady Booch author of Object
Oriented Analysis and Design with

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.

Robert C. Martin, Clean Code: A Handbook of Agile Software


How to remove the fear when programmers are asked to work on your codebase



  • Sharing Projects/Codebases within a software development team is hard.
  • Programmers sometimes outright say it can’t be done.
  • This affects project deadlines negatively.
  • This is a type of Muda(( Information Waste which is rework
    • the Author already created the codes, debugged it and made it run.
    • then the next developer has to do it again because THERE IS NO AUTOMATION NOR DOCUMENTATION (see comic above)

Proposed Solution

  • Borrow proper README formats from opensource projects
    • there are many guides/templates available online like this
    • this removes the question of WTH do i do with this repository?
    • this removes the muda rework because a copy+paste guide is already available
    • this allows a new-developer-in-the-project to quickly start working on business requirements and not waste time on technical specifics that should’ve already been handled by the author/initial team who worked on the project.

Quick Breakdown of the sections of the proposed README format

greatly inspired by

  • Project Title – a meaningful name that indicates the problem you are trying to solve
  • Getting Started – any piece of context you wish to share to future maintaners
  • Prerequisites – skills you need to have, tools you need to know and software needed installed
  • Installing – how to get the project runnning~
  • Running Tests – how to ensure that the project really works before others start working on it
  • Deployment – how to release the finished project and some details where the application is actually in use right now
  • Built With – tools/frameworks used, to quickly match people who could work on this project.
  • Contributing – Coding standards / Architecture Design Decisions so the codebase will retain looking like it was written by a single person and therefore easier for future maintainers to understand.

Proposed KPI for a maintanable Software Project

  • Software Developers (Especially Tech Leads) metrics should include “how easy is it to onboard new developers on projects that I led”
    • this is in contrast to smartass developers who take pride in obfuscating their code because it makes them look smart.

From Wikipedia

Muda is a Japanese word meaning “futility; uselessness; wastefulness”,[1] and is a key concept in lean process thinking, like the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (the others being mura and muri).[2] Waste reduction is an effective way to increase profitability.

From Wikipedia