Skip to main content

Deals You Can't Miss

1 Year Subscription

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.


My Enterprise Software Development Story From Development To Deployment


  • 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. It's high time you embrace the new era of chaos.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t