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

Shift left was applied to testing and then the testing scope which was initially functional expanded to include performance, security and resilience. So far it is fine, the problem it brings is when the experience aspect is shifted to the extreme left. This ends up with product having endless loops of perfecting the wireframes and experience aspects to get a perfect shot at the finished product.

Imaging you are playing paintball, you have to shoot down very very fast erratically moving drones. You get two options, (1) a gun which can be reloaded as many times as you want and fire in quick succession but needs 2-3 hits to take down a drone, (2) a gun which can be reloaded only once in a few minutes and takes down a drone in 1 hit. If you are given 10 minutes and you win based on how many drones you take down which would you prefer. If you prefer second, then you have shifted everything to the left without the option to learn from your misfires.

Shift left should be for the delivery mechanism. Functionality, security, performance, resilience all should be tested and if at all they fail should fail very very early, closer to the time the code was committed. Along with this an experimental and dark release setup that can be used to learn user behaviour & adoption. This helps the product send umpteen changes to the end user and get the one that works to remain in production.

There is a lot of value in UX research, paper prototype, wireframes and illustrations but when shift left is applied to this, then each iteration and increment becomes very expensive and forces people to figure out as many variables as they want, which is not possible to discover until an end user uses the system.

Misfire is a given in product development, if we shift left everything we have less chances to learn from our misfires. We should also optimise to validate the hypothesis with a working software, so an idea should see reach the customer for validation as much as possible.