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 started my career with a waterfall style development taking a finished product after extensive quality control to the customer. Release was a major event, marked in our calendar where no one can take days off and the weekends are taken for granted that you will be at work. People spent a considerable amount of time on go/no-go calls and then a marathon effort to make a release happen. The releases were also followed up by hotfixes, bugfixes and minor enhancements which took a toll on the people making it happen.

We think waterfall is extinct now but it is not. There is still a great fear in releasing software to end users. We have progressed so much in software development that a lot of boiler plate is getting taken care by frameworks/tools, extensive automation capabilities help remove toil, abstractions and off the shelf components make it possible to develop and deliver something in matter of days and weeks not in months and years. Combine this with tech practices advocated by XP, we have a very agile tech team.

Photo by Pavel Danilyuk on Pexels.com

No matter what agility comes in technology, the inertia from the business and the product always robs the advantage of agility especially in mid and large organisations. Product teams always want to put a finished product in front of the customer that will wow them, in reality software development never sees a finished product, you just stop giving updates. Tech teams are capable to ship smaller increments of product, in a great frequency in the order of multiple times a day. In a mature continuous delivery enabled team setup, every commit or merge can go to prod within an hour.

Should we call each deployment as a release then. Deployment is a increment to the software, release is a logical grouping of many increments. Branch by abstraction will safeguard existing functionality while new increments are getting delivered and it will be a matter of another small increment to consider it as a release.

I have worked with some teams where the lines blurred, there were only deployments and no releases. One such team had to revamp a user profile page which aimed to declutter the UX and make it more easy to use. The team put a toggle button to preview the under construction page on the current user profile saying “we are revamping the page and let us know how it is coming along”. The designer also asked for feedback from the end user by providing comment ability on the new screen. Along with the comments, analytics was also baked in the new page to learn from user behaviour. This led to super fast iterations of the design as the feedback was instant and from real customers who use the product every day.

Coming back to the inertia from the product to go with a release mindset, this rots the continuous delivery mindset and quickly the teams align to a release mode making it slow, effort intensive and tiring. Decouple releases and deployment, product evolution is supported only when you can iterate as fast as you wish.

by on

I regularly interact with a wide variety of candidates right from college graduates to very senior engineers, one story that I keep hearing is that every one prepares a lot for the interviews solving DSA problems. It is like rote learning, one has to keep practising a lot just for the interviews.

I have never understood the need to test the depths of programming for regular software development. Software development in most cases require skills that does not need deep understanding of data structures and algorithms. A fundamental knowledge of programming is enough. What is needed is communication skills, it is extremely hard to specify software requirements in writing just like how input and output are expressed in competitive programming.

Photo by Nemuel Sereti on Pexels.com

A programmer’s biggest challenge is to understand the value and intent behind a requirement, what impact it can create for the business and come up with a solution that is easy/quick to develop, maintain and extend. The main point here is, it should be fast/easy, cheap to develop/extend, should be maintainable and not be hard to fix when critical flaws like zero days surface. Communication, discipline on keeping up with clean code, grit to keep the code continuously tested, integrated and deployable are key skills. Product owners will need multiple iterations and increments to get to a desired state; faster and easier the communication then faster is the desired result.

A big myth in hiring space is that if programmers are good with DSA, then we can throw any problem and a deadline at them and we can achieve a lot. This mindset is the root cause of a lot of software rot, making it extremely hard to onboard new developers and keep existing developers productive. My observation has been that candidates tuned so well to crack DSA problems expect clear specifications often broken down to LLD and tasks with clear input and output. They find it very hard to collaborate with peers or train new developers. When they face ambiguity, they go haywire instead of resolving it; often end up treating it like competitive individual sport whereas software development is a complex creative process.