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?

Before you begin reading  you must watch the short 45 second clip.

This video towards the end shows a hesitant thief mustering the courage to pick a pocket. On hearing the kid snap his finger he is disturbed and out of fear drops his idea and walks away, hence a crime has been prevented from happening. It was a coincidence that the thief thought that someone else was looking at him.

I loosely compare this to the Continuous Integration server where the build turns RED for the standards we set. Most of the bad parts while coding goes in inadvertently during the rush hour of check-ins. I usually observe the rush hour to be close to the end of the day and the next day, the refactoring is put into back burner which grows into tech debts and makes you repay at a later stage. Along with the other devs in the team we set some simple rules in the CI to fail the build. The rules are

  • More than 12 lines in a method
  • NPath complexity more than 4 in a method
  • More than 4 lines of code copy pasted across any file

An intentional check in to avoid these rules and send in a bad code could not be prevented; but someone in a hurry or tired individual checking in gets a hint that code could be bad. A quick introspection will lead to corrective action and things could be addressed then and there instead of carrying a tech debt. The rules above are neither comprehensive nor does this guarantee awesome code, but it has caught me and others red handed when looking for quick gains. We are exploring more options to configure the CI to help us keep on our toes.

Hamcrest matchers provided a good way of expressing the assertion in the tests. Combined with the method name and the way you write your assertion it becomes expressive. Bringing it into the middle of development phase when all the other tests have been written using regular assertions was not so desired. So restricted that to starting something from scratch.

Java programmers would have gone through the boring ‘for loop’ and collections manipulations for any applications. Both in the tests and production code it was almost necessary to transform view objects (a necessary evil) to and from models or go through a list and collect the just the names etc. CollectionUtils from apache provided a good way to work through the mundane for loops and do most of that stuff. CollectionUtils.collect(list, new Transformer() {<transformer code>}),  CollectionUtils.select(list, new Predicate() {<predicate code>}) did good help to reduce remove the for loops out of sight.

I then moved on to Groovy which is when I got smitten by the ease at which we can use collections. All we need to do was to call .each or .collect on the collection and put the respective code in the closure. Having tasted this going through the CollectionUtils in java was suddenly looking like an eye sore on the code. I discussed with another developer (incidentally his name is the same as mine) about the problem. He immediately jumped in and said that he had used LambdaJ and it uses Hamcrest matchers. We immediately explored through the code and started replacing Collections.sort to LambdaJ alternative. The code

Collections.sort(personList,new Comparator() {

//comparator code

})

changed to Lambda.sort(personList, on(Person.class).getAge())

Once we tasted success with the first replacement, we went scouting through the code for “for loops & CollectionUtils” and ended up having interesting looking self explanatory code like

Lambda.filter(having(on(Student.class).getAge()) ,is(greaterThan(20)),studentsList)

On doing the static import, the Lambda prefix also disappears. The power of Hamcrest matchers and LambdaJ’s thoughtfully made collection utilities help in making Java code more easy to read. It also has brought closure support to Java (Limited somewhat due to Java’s nature) which looks promising but I am yet to explore its full potential.

As more and more people are getting their hands on other programming languages and switching back to Java due to client requirements are making Java more and more readable and easy to use with these kind of APIs. You can spend more time thinking about the functionality, design rather than getting bored with boilerplate stuff. What else is in store from polyglot programmers?