by on

Demoes are always concepts, they are not a showcase of capability instead it is an artistic impression of what is possible in the end state. A frequent repeated pattern in the enterprise software I see is that – someone builds a something eye catching in a short turnaround time, it gets coverage and people are assigned to take it production and then it stalls like how the loading icon appears when you try to watch a hd movie with a poor connection.

Photo by SHVETS production on Pexels.com

I had been an advocate of rapid prototyping & development and XP practices all along my career. It is in my best interest to find increasingly faster and sound ways of developing software. The first problem to solve in software development is never programming, it is to figure out ‘are we building something that people would want it very badly?’ Building something was expensive so people had to be extra careful to understand if they are going down the right path. With advent of more and more easier programming tools, the building part became easier and easier to the point right now that we can do lots of work in an extremely short window.

Photo by Deniz u015eENGu00dcL on Pexels.com

This paved way for ‘Let us build first and check if it works’. This is where several people stumble and I am reminded of the infamous developer quote ‘It works on my machine’. ‘Works’ means different to different people. Productionising an application is far from development completion. It involves architecting, designing, testing, certifying, securing, scaling, monitoring and on and on. The UX has to be top notch, architecture should be easy to scale, design should be able to add more components with less effort, when scaled and distributed it should take advantage of economies of scale and bring more returns.

Another bigger problem I see with the current state of development is that zero to one has become an easy to solve problem but people are stuck at level one and very few have the capability and grit to move beyond the starting point. What has in fact happened is that the starting line has moved from zero to one, the difficulty of getting to the finish line still stays the same. I feel it is momentary that people are getting carried away and impressed by the quick turnaround time.

Only when all the parts of the cycle from start to finish are transformed to a rapid development pace, then demos will be an engineer’s showcase not like an artist’s impression of how the finished product will look like; which is easy to demo and hard to ship

by on

I have observed one common thing across different organisations I have been associated with, how the appraisal process works. Bell curve is the default standard. Over the many years; I have seen this kill very high performing teams by promoting silos, heroisms and also a rat race to avoid the bottom.

One place I remember very well was when I was coaching a hand picked team. This team was assembled by the business unit leader to adopt XP practices to switch from waterfall. This team was phenomenal, picked up concepts and intents of XP very well and showcased to the entire org on what lies ahead with the new ways of working. Then came in the annual performance review. Until that point I have not see the ill effects of a bell curve, it was always give your best and reap the benefits.

Lion and fox chasing impala on dry savanna grassland
A lion and a fox chase an impala across the African savanna at sunset.

This was a curveball that no one expected in the team as they thought they were immune from the old ways of performance management. As per the process, one of them will be labelled as a non or poor performer and penalised. So much for a team of handpicked top performers in the org. In the end, the one who was named as poor performer left the team and the org. It was a lose-win situation, the org and the team lost a good developer but the developer got a bigger and better role due to the upskilling.

When I asked an executive about this, the answer I got was that “It works for me and everyone around. Why fix something that is not broken?” That was an answer that stumped me on how normalised this has become. I know I can’t fix their process overnight but planted a thought on them by reversing the decision process, why are they limiting the number of people who can perform better than that is expected of a role. Aren’t they signing up for less?

The executive accepted but said that too little can be done about at large corporates. Many of them are too big to fail and have a good market share that it is hard for them to get disrupted. I did not give up though, I was able to persuade some of the smaller companies that I was involved to look away from this bad system of finding a prey and become a prey. Bell curve or forced ranking is quite detrimental to collectively up the game for an organisation.

by on

I keep thinking about abstractions all the time ever since I begun to understand large scale software development. In the early days of programming I took a lot of pride in understanding code in depth and writing the most efficient code. I was fortunate to start learning programming from the rudimentary steps like creating adders using logic gates. From there on progressed to assembly, BASIC and C.

If we take a step back, late 90s and early 2000s we are talking about super expensive hardware in Indian currency terms. To give an idea, a simple desktop pc setup costed the entire year’s income of a middle class household. On top of it internet had dial up charges and subscription charges. This meant people had to be frugal and extract the maximum out of their machines. For many years I have never been able to run an IDE on my machine because of limited hardware and ended up using text editors. Also efficiency was at the back of my mind of writing small footprint programs which consumed a lot more time than producing software that is reasonably performant but needs good hardware.

Collectively this scarcity based mindset made a lot of people approach with frugality, often having a lower specced computer for their personal use. Even when hardware became more affordable and software development technologies leapfrogged, I witnessed that people fought against upgrades and learning newer ways to do. Developers refused to learn to work with IDEs which made development significantly faster, test automation was in no one’s land as both devs and QAs avoided adopting it.

Photo by Andrea De Santis on Pexels.com

The difference between the teams using IDEs, continuous integration, build and release automation, test automation all which consumed a lot of hardware was around 3-4x. It was very visible that we removed dedicated roles like infra engineer, DBA, reduced the dev-qa ratio, reduced the number of leads and managers. A 40 member team was replaced with a 12 member one when high degree of automation was used with an added expense of hardware costs but overall it was much much better than running a 40 member team. One thing that changed which I did not expect was it increased the number of Business Analysts needed now to define the requirements better.

Only a few companies succeeded in taking advantage of this and it took more than a decade for people to catchup. We are at a similar point now to take advantage of new tools that can change the team composition and get more out of less in software development. Just like in previous waves of development, it is not going to eliminate people entirely from this. Instead it frees up a lot of people to solve more higher order problems. Companies can now focus exponentially on what was traditionally expensive with less people able to do more. Examples I can think of is accelerating development of new medicines and treatments to the extent it can be custom made for every person; predict, fight and prevent large scale natural disasters with precision; strengthen the security posture making it more expensive and difficult to cheat; revolutionise entertainment by localising with actors, accents and languages than traditional dubbing and subtitles. The list goes on, jump on the new wave and ride new highs.