The Uh-Oh Decade Of Enterprise Software Development

This was a decade when it was not easy for a start-up to even give birth, for things were so complex and expensive too. There wasn’t promulgation of open-source tools and technologies and the cheap cloud that takes so much of the pain out from you for infrastructure management was simply not there. This was an era when one enterprise was painfully dependent on other for the specialized services that the other provides. This mandated the need for Project Managers over Engineering Managers. And the viral joke in the community was something like, “If you got a person in the development team who is not capable of any of its function but is surviving by his glib talk, make him a Project Manager”. The development team use to hate the management for this. But what was the management’s point-of-view? For them, they saw an opportunity in darkness, in that they wanted someone who though was insincere in his work, can thrive on inefficiencies and hopefully be loyal to the company in identifying the inefficiencies of the third-party service providers they depend on, so as to reduce the cost of their dependencies. The enterprises were so damn focused on the operating cost of dependency than the delivery efficiency and quality of the software product being deployed. Very early on I was lucky to have learned all these by virtue of opportunities that I had in my platter and the unstoppable curiosity to learn more. From that chaotic world we have moved on to a different chaotic world of software development. This post however is to story tell in brief about the chaos in the enterprise software development back then. Times when development teams didn’t use nail-clippers.. My Enterprise Software Development Story From Development To Deployment in That Era Local development on IBM’s then famous RAD-IDE (Rational Application Development IDE) that came with integrated IBM WebLogic Server, used to be so fast that with every deployment of code changes, the server would force you to get out of your seat and go for a walk/water/coffee/just-a-break/do-multi-tasking. No wonder multi-tasking was such a hype back then in that time. Because the local WebLogic server ate most of your local resources (memory, processor, etc.), typically, the developers used to have their development DB in a separate local server environment. In some cases, this was further complicated when all the developers were literally sharing the same remote DB instance. The teams used to beg literally for separate DB instance per developer. Outright unproductive ways of building software was how we jokingly defined “Enterprise Software Development” among our peer group of developers. And if you think that was all there was to this circus? There sure was more. The climax is always the release phase. Development team builds the big-beastly WAR/EAR file and hands it over to the Ops team. Ops team takes over the artifact and deploys it in the IBM WebLogic Server. This situation was further complicated when the Ops team and deployment was done in IBM server environment by IBM folks. Why? Because, you had to plan every release of yours, raise a support request with IBM, follow-up on approvals, submit artifacts, and wait till deployment was done and you get the notification from the IBM Ops team. The situation worsens and becomes a nightmare, if for some reason you had submitted a wrong artifact or there were critical bugs in application. Thanks to the Project Managers at IBM that crafted the contract with your company, you were left with no choice but to raise a high-priced urgent-deployment request. The urgent-deployment tickets would typically cost the company double the price of ordinary support-ticket. But how did it affect the developer? As if the burning crisis of deployment is not enough, the Project Manager would drag the poor developer into a meeting room to do RCA (Root-Cause-Analysis). Damn, such was the stressful life of a developer. Good riddance to that era! Or are you still in that era, even today? If you belong to the development team, you should look out for change. If you belong to the higher management, you should seek help from experts. Either way, it’s high time you embrace the new era of chaos. Embrace change and gear up for a better tomorrow in 2019! This post is also published in my other blog channels — and . Codonomics LinkedIn