Technical Divide

Being a software consultant is an exciting career as it exposes you to multiple client locations - thereby widening your vision to multiple businesses, software practices, technologies and office cultures. It not only makes you appreciate how software has been an enabler to core businesses in our times but also allows you to compare and contrast the software practices at various firms.

Based on my personal experience I've come to the realization that a serious class divide has emerged amidst the fast paced growth of this industry. I call it the "technical divide". My definition of the term is the divide between software practitioners who are following the software best practices, right toolsets and design patterns vs. those who do not.

The problem that this divide creates is manifested at several levels - from charting out enterprise's software blueprint right down to engineering practices followed to build the software landscape within the organization.

In today's world where outsourcing and adopting SaaS offerings are pretty commonplace, some companies think that they can bridge this divide just by passing the buck to providers of these cost effective solutions/manpower. The current recession and ensuing cost optimization models in the software shops has not helped the cause. The cost of software quality is being blatantly overlooked. Immature adoption of technical buzzwords(read agile) leads to a software architecture which is half baked and incomplete. The result is a huge pile up of technical debt in the corporations.

Being an optimist and a passionate software professional, I look forward for the turn of events in this space. But there is no silver bullet in my opinion to bridge this divide. The only way it can be done is by allocating the right budget to IT division and ensuring the right engineering discipline. Otherwise like the economy we are just passing the mess that we are creating in the name of cost optimization to future generations of software profesionals. There is a fine line between being cost conscious vs being cheap. Hope that line is not crossed while preparing software roadmaps. Otherwise this technical divide will be too huge to cross.