Richard P Gabriel introduces the term “habitability” in the context of software development. It is about how good is the code to navigate easily and understand what changes to make. He relates this one directly to a person living in a building. If the building is simple, well lighted and ventilated then it is very habitable one but if a building has been designed to win a awards then it might not be an easy to live in place. Some thing like how many people will choose their place of work to be Taj Mahal.

This topic evoked a mixed response in me as I was very much inclined to aesthetics and reduced number of lines. This was definitely food for thought as I had never thought about me being a builder and want to build dwellings such a way that it would be a habitable one. The next few days went by pondering over the thoughts again and also discussing that analogy with some peers. We all felt that if we programmers consider ourselves to be builders (coders) then our aim should be long term life and habitability of what we build.

How to know if the code is habitable or keep it habitable? My inference so far has been that not to treat any software as a finished product. Developers should consider that the system will always be under repair and should keep it in a constant repairable state. The idea might not get along very well with everyone, but so far any thing which I have coded and considered complete has been changed within a short period of time. That means there is nothing called a finished product, which can be related to leaving a semi-finished building to both engineers and dwellers to start using and making changes at the same time.

The more habitable a codebase is, more is the sense of ownership and responsibility. I will finish with a snippet from the book

When people lose the sense of responsibility for the environment they live in, and realize they are mere cogs in someone else’s machine, how can they feel any sense of identification with the community, or any sense of purpose there?