Many software developers are in favour of a kind of laziness, the laziness to think, design and test clearly. Instead they are very active in creating pages and pages of code, endlessly run the application in debug mode doing a treasure hunt for bugs and spend countless hours fixing bugs and regressing many others.

Steven Wright, a standup comedian says, “Hard work pays off in the future. Laziness pays off now”. That is very true for the brain, for subconscious part of ourselves, any new thing is an irritant. Brain will find a way of rewarding itself with chemicals when it is able to gratify very quickly, thereby rewarding more and more lazy behaviours.

It is super easy to nudge someone to be lazy than the other way. That is the reason a person may skip gym for a whole week but will find it tough to go to it for a week. This is the point where software development mangers do a double whammy by saying “I want the output fast, I don’t care about quality” thereby disrupting the delicate balance the developer had between quality and speed.

As a result, the developer ends up adding a new flag, changing all the methods from the controller to the repository to take that flag and finish off the work in a record time. The developer may also get rewarded with the developer of the month award. Other developers get the idea, they eye for more awards and recognitions.

The worst thing to teach a teenager is to borrow money and buy to fulfil their immediate needs. The teenager will never be able to grow out of that nasty habit. The same applies to programmers, if you tell them early in their career that they can compromise on quality to achieve speed, they are not only going to ruin themselves but also take their team down along with them.

Quality work is like investing in compound interest, you can only realise over time but in unimaginable levels. In one of our teams, we had a strict adherence to quality routines. The manager had only one yardstick to measure, it was no of stories delivered. The speed of the team went up to 8 times in the 12th week when measured against the first two weeks. We had to ramp the team down to keep up with the flow of the requirements.

For many, laziness pays off now but makes them and others around bankrupt in the longer run

Writing a piece of code and seeing the output of that on a developer’s machine has become much trivial with latest tools and frameworks that we grossly underestimate the cost of maintaining code once it is written. It is observed a lot in the UI code where the impact on productivity is huge.

Last year during one of the discussions about developing a new product which has to be tested for product market fit, we made sure that the designers had to use directly off the shelf components of Vue.js through Element. Initially though there was a bit of hesitation from the designer later on we collectively realised the gain.

When designers used only ‘off the shelf’ components, they were able to create screens that were too easy to translate into code removing the resistance to move things from idea to production. As there were neither custom components nor custom interactions, we did not have the need to have a huddle with the design team often to figure out if something is doable or not.

Though there is a risk of non compatible upgrades in third party software, the workaround is much simpler compared to the pain of going through the maintenance of custom components.

The tendency to build ourselves is very high when there is a cost to introduce third party software, but the same inertia exists in adopting open source work as well unless the frameworks like spring are ubiquitous.

“Why are there no tests?”

This question is often answered with “We do not have enough time to write tests, we have very tight deadlines”. Whatever the crowd is at a hospital, it will lose its business if it decides to skip hygiene practices. You don’t see them reusing needles & syringes or not discarding wastes properly. It is practiced only because it is visible, if testing is that visible, it won’t be skipped.

Any profession which has a sudden need for a lot of skilled people and is managed by unskilled people is bound to lose its practice of craftsmanship. Craftsmanship requires discipline and time, a professional’s job is such that it is very hard to get it wrong because of strong unconscious competence. Highly competent people get great results in a shorter amount of time and effort, in fact they make it look like it is effortless.

Businesses have to keep running else someone else who can run faster will eat them for breakfast, but that urgency should not percolate down to every last bit of detail which turns from a sense of urgency into haste. What are some of the things that should not be lost in haste during software development?

-1. Test driven development – Without this, we are just fooling ourselves that our work is of high quality

0. Continuous integration – This does not mean just running builds on every branch that has a commit, but developing on trunk and making sure that there is a collective progress.

1. Quality code – Human readable, domain reflecting code that is easy to read, understand and modify

The list would go endless, but I am sure most of the teams don’t follow any of the above three. Practicing just the above items requires a great amount of discipline, time and effort in the initial stages which will pay back compounded in the long run. Then it is easy to achieve milestones which were never thought about.