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.