Productivity Entrapment
I took upon myself to write this article even though I don’t necessarily have any writing experience. But, as it stands, productivity entrapment is by far the most difficult thing I ever had to deal with during my career as a developer.
There are of course a few examples I can provide, but my goal is to highlight the process and possibly the reasons which ultimately result in poor productivity due to past decisions.
Let me just make a clear distinction and state that I’m not pointing fingers at technology choices just because someone would find them unsuitable for some personal reason. I’m talking about those situations when, regardless of what topic any particular group of people are looking at, no one is able to come up with a better solution than: “it is what it is, and there would never be a budget to change it”.
First time I’ve noticed this was a mix of poorly setup infrastructure, together with complete lack of Continuous Development practices, which lead to outrageous efforts in cherry-picking changes across multiple branches and projects, in order to turn them into a release.
The second time was the conscious choice of a CMS, which came with a price tag and a contract attached, and for that reason alone it made it impossible for someone to even consider removing it from the tech stack. Moreover, the issue was with the type of work that was being done with this CMS, dictated by how the products (not the codebase) were marketed, which led to a large portion of the time the team had to go through their sprint being spent on repetitive tasks, often without a safety net.
The third time I noticed was the adoption of a new technology, which by itself wasn’t the problem. But unsuspectedly also adopting bad practices from the community using this technology. All done eventually with less dedication to small proof of concept projects that would otherwise reveal some of these technology pain points. If I remember correctly, maintaining the tooling and constantly tracing the application monolithic state, was increasingly difficult and painstaking.
By then I should have known that something like this was bound to be the reality of any product in which I worked. But maybe the fact that we tend to forget these things is one of the reasons why we keep committing the same errors over and over again.
Then came one of the worse mistakes I have ever seen. A large piece of a company’s technology stack being adopted by upper management, for reasons that the engineering team was completely oblivious of. Well, maybe the fact that prior to transforming the company and creating an engineering team, the same company decided to order the products from a 3rd party digital agency. Even worse when this agency was a partner of said technology and didn’t actually employ a single developer, other than contractors that were just in it for the high income and low responsibilities in the final product. This situation turned out to resemble someone trying to tighten plumbing with a hammer.
I have since witnessed many other examples of pieces that just don’t fit in the work we were trying to achieve, and often stumbled upon extreme resistance of addressing these issues.
Now, at first, seconds and thirds, I always assumed that was my lack of communication skills preventing me from properly illustrate how damaging a particular situation was. But, soon enough I started to realise a pattern. Ignorance and/or over-ambition.
I don’t mean to make anyone uncomfortable with those two adjectives. But sometimes we need to call things by their names.
Ignorance of most of the aspects that impact a software product. Not just “how much time does it take to code something” or “probably more developers means faster work”. Those are either naive or completely out of place considerations. Ignorance that most software projects have to be analysed before any single decision can be made. That teams need to consider the workforce, the knowledge base, the effort required to maintain solutions created for the project. That build times can and will often increase. Data will always be required to be more restricted and shareable at the same time. Regulations, integrations with third parties, scalability. All these lie under what often many of the decision makes ignore prior to making those decisions.
Then comes over-ambition. This one is the worse reason I witnessed for rendering a team’s ability to work to an almost complete halt, due to poor choices in completely absurd and unrelated technology, that is just painstakingly hard to build upon. That is absolutely controlled by an outside party with which the company has a long-lasting contract of millions/year. And all because one individual has personal interests in obtaining that contract and was put in a position where he can actually just do it with little or no supervision.
This results in that CMS which is unable to synchronize data between non-production environments. Is unable to integrate well (or at all) with previous technologies the business depended upon. Has no good solution for data protection or backup.
The CMS which acts as a web server, rendering engine, and authentication layer.
The other CMS which although is quite powerful, requires a small frontend team to constantly build controllers for various data types, instead of other that would provide those same controllers out of the work done by a much larger content editing team.
The DevOps solution that is just subpar with its competitors, but “comes free together with another package that our CFO decided to buy”.
Just to name a few. The point is, many projects don’t innovate, grow or deliver value because they are essentially dead in the water. Their engine has failed a long time ago, and someone is blowing at the sales, expecting that Newton was wrong all along. Many companies don’t realise that in order to build a good product, with fast-paced sprints, which are able to implement new features, new marketing, more content, fix bugs or basically provide the business with choices to compete in this extremely competitive market, one must look at the foundation of those products.
For a car manufacturer, it would be the factory in which those cars are built. The distribution channels for parts, etc.
For a pharmaceutical company, I’m sure the safety of their labs and the quality of the equipment they use also has a major influence on what their collaborators can or cannot achieve within a specific time frame.
For any business, there are conditions that can will impact positively or negatively the outcome of their products, ideas and business plan. I am convinced that there are definitely points of no return for some. Being it when the money runs out, the customers lose interest, or the reputation was affected by a period of lower quality. Unfortunately, I’ve been trying to fight these windmills with relatively poor success, and as I discovered it has nothing to do with my ability to unveil them. It’s often bad timing since I arrive too late to make any difference (and now the budget is just prohibitive), or strong self-serving people preventing me from contributing to the change the situation needs.
I have no post mortem solution other than hard work and perseverance, but I can definitely say that I’ve seen much more time and money being wasted in the wrong path, which leads to redundancies, defunct products, and general unsatisfaction than I ever have seen goodwill and people coming together to actually make something work and evolve.
Would be nice to find out about good examples of when situations like these were avoided, by whom and how. So feel free to comment if you have them.
