Someone I met last year mentioned that the reason the 737Max planes went down was because it was coded by developers from a country where there was no aviation engineering experience. This person also went on to say “What else can you expect from people who are paid less than 9$ an hour wage”.

What is evident from this person’s thought is, irrespective of all the experience in aviation, expensive engineers, highly paid directors this crash was a result of a developer who coded as per the specification given not because of the carelessness of the others, in spite of airline industry being one of the hallmarks of safety standards.

Why this kind of thought irritates me is that a lot of people equate cost to quality. If something is not expensive, it is of poor quality. Expensive flights like concorde ran into losses, nobody eats at michelin star restaurants every day even though they are the best in the business.

It is very much possible to reduce cost without cutting quality, recent example I could think of is SpaceX that too in space technologies which is “Rocket science”. If something has failed, it is not necessary that the component of poor quality always costs the lowest.

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.