Common Pitfalls of Enterprise Programming

Rahul Bhattacharya
Prolet.pro
Published in
6 min readJul 6, 2018

The problems in todays enterprise software are numerous. Most projects do not get delivered and its a gigantic waste of human capacity and intellect. Instead of delivering great software which can make humanity better, enterprise software is stuck in petty politics and unnecessary processes and jargons. Imagine if we just streamlined software, how much the world economy would have benefited from the same.

In my experience the reasons for enterprise IT failing, are quite obvious and in our face. But no one seems to talk about it and like mindless zombies we come to work everyday, and we have reduced an innovative and creative profession such as programming, into a total waste of time. Just to talk a little bit about myself i have been a programmer for the last 15 years and i have seen a lot of corporations just throwing millions of hard earned money into IT projects which never go anywhere. So here are some of the very obvious pitfalls

Agile is not very agile

So every company wants to get into the agile bandwagon right now. They think that its some sort of a silver bullet, which can get rid of human stupidity. Let me elucidate this a little bit. Say you want to build a piece of software which needs to solve some business function in your organization. A really easy way to go about this is to just hire a bunch of good programmers to start. Then you need to have a meeting with them to explain what you need. Then you have to negotiate with them, the project delivery milestones. Now you have to leave it to them to figure out how they want to accomplish this. You can actively check with them for any updates, or you can be more passive and only check with them on delivery milestones. Your team can use modern communication channels like slack, hichat etc to relay information among each other and you. Quite simple isn't it ? But instead of that, we hire Scrum master, Product owners , QA testers, Architects and finally a few programmers. We force the programmers to endure endless meetings like standups, grooming, planning, retrospective, program increment planning etc where the decisions are always made by the non programmers and the programmers are just there as passive bystanders. So in a way you want to take away all the power from the programmer and trivialize and insult their profession and then expect them to write good software. Well duh !!!

Solution — for god sake just hire developers in your teams. Scrum masters, PO, testers are redundant job functions and can be easily done collectively by the developers. Agile is not written in stone, let developers find out what works best for them, and not let managers shove outdated paradigms down their throat.

Corporate Hierarchy

Enterprise software unlike startups have to provide their programmers a progression path in the enterprise food chain. So they come up with roles like tech leads, committers, principal architects, enterprise architects, directors and managers. This way upper management feels they can keep people happy without spending too much money. That programmer might leave for higher pay, so just make him an architect. The cost of this disastrous strategy though, is much higher. Let me explain why it is so. Most people are realizing that non programming architects are a bad idea, because the cost of their bad decisions are way higher as it impacts your entire organization, instead of the tiny little thing the developer is working on. And almost always architects make bad decisions, not because they are stupid, but just because they are way out of touch from real world programming. The moment the management promotes you to be a architect the expectation is that you stop coding and start pondering on the more erudite functions of your software landscape. And then come up with some harebrained ideas which your so called hoi polloi developers have to implement. End result- your architects have taken your entire development organization into a free ride to nowhere on a multi-billion dollar and time guzzling jalopy of a project which drives your company to bankruptcy. One more factor that is prevalent in some countries like the US is its peculiar immigration system. In US most programming workforce is visa holders and the managers, architects etc are citizen/green card holders. So the country’s immigration system is partly responsible for the disdain for programmers.

Solution — Be an engineering driven company where being a developer is something to be proud of, and meaningless managerial roles are not required for people to be happy about themselves.

Microservices inside Corporate Hierarchy

Oh we all love micro services don’t we ? Microservices like any other thing was supposed to make developers’ lives easier. It was supposed to give power back to the developers. From it came devops, developers can quickly build their own little toys and get it out for the business to see quickly and every one is happy and swell. Well but corporate hierarchy and job security was there to spoil that party. The sheer gall of developers who assume that can live in their small little cocoon of the nifty little micro service they built, is unthinkable. If this happens what would that architect , that director (who spends more time fishing than in office) and all other so called smarter people do ? Let me explain to you a dirty little secret of how micro services in the enterprise actually works. First they will say we promote micro services and probably let you build that node.js or springboot app that you wanted to build. Then they will say we need to build frameworks (be careful the moment some one utters this word) to centralize and control the work. So the developer is not allowed to use the nice little opensource library that he downloaded from github, and got everything running in one day. You have to use the enterprise framework instead, which does one tenth of what the opensource library does, and does it very poorly. Next the architect will fill this framework with as many hairbrained ideas that he can come up with, and go around talking about it till you ears start to bleed. Since no one can fire that architect, every one is made to reluctantly accept that framework and use it in their projects. So automatically project estimates and deadlines go out of the window, and so does your motivation. Now comes the next stage getting your software in a environment where the rest of the organization can see. Now comes devops. Devops as far as i understand meant developers who do operations functions too. So developers can write their code and get into the docker containers or chef environment etc. But corporations had an army of very incompetent linux admins who need to find their place in this new scheme of things. Earlier all they did was restart servers, and now you assign them the role of gatekeeper who sit there and lord over the developers. The way they do it is by controlling access. So you don’t get to do deploy anything but go through them and they feel important about themselves by pushing buttons.

Solution- Embrace Micro services in form and spirit. Microservices are a great way to empower developers to quickly deliver without being bothered about bullshit peddlers in an enterprise setup. Do not let architects and their likes sell you frameworks (inhouse or purchased) unless its backed by an open source community. Devops is literally developers plus operations, do not build centralized monolithic devops teams whose sole purpose is to create hindrances and processes which don’t serve any function. Again let the developers decide how they want to distribute their software which they built.

In conclusion i think we need a new manifesto. That manifesto should be much simpler than agile manifesto, and should contain some of the things which i mentioned. This is the need of the hour, to save this nice little thing which we all love and enjoy to do, Programming !!

--

--

Rahul Bhattacharya
Prolet.pro

Author of skywayfinder app to navigate skyways. working on different things including blockchain, iot, Kafka, k8s