Why on earth would someone have coded it this way? If you are a developer, you’ve probably said this many times, typically while banging your head on your desk. But sometimes – given some perspective – you may realize why someone else’s choices made sense at the time. There can be really good reasons for a decision, ones we lose track of over time. It’s likely this happens more often than we think.
Programmers and PMs get used to working with and around bad decisions. It’s a given, especially when technology changes so often, that not every technical or architectural decision is going to be the right one. This blog has a good summary of why we should ignore the myth of right tool for the job.
I’ve worked on applications where the underlying technologies had to be changed, and it was a challenge to pivot. But it was doable for several reasons. Good coding practices that separate an application into presentation/logic/IO tiers made it easier to update one component, without losing the entire investment in coding. Modern applications, like our 7 Series, are developed to be flexible in how they can be deployed across different platforms.
Of course, you are never really coding from scratch. For one application I worked on, we had already captured business rules, both in documentation and in the code, so it was relatively easy to recreate it in another stack. Plus we already had test plans, test data, I/O modules, and the live system to compare against.
And while it may seem like a waste of effort to rewrite an application, much of what we learned from version one of that particular application helped us do a better job the next time. For example, originally our menus were static and we spent a lot of time coding menu changes. For version two, we knew we needed to switch to dynamically building them.
Failure does not typically lie in the choice of technologies, but in an unwillingness to make a decision to move forward with a project, and invest in the people needed to build it. I’ve had managers who could not do that, and defaulted to relying on workarounds. While that might seem better than implementing something with the wrong technology, there is a cost to inaction.
First, of course, is the time wasted managing workarounds. I spent an entire year writing one-off programs to make database fixes because there was no decision on implementing new functionality in an application. Our sales team sees the end results of this all the time, where a lack of organizational commitment to analytics means that developers get stuck writing reports, even when end users can and want to self-service.
Surprisingly, that’s not the worst that can happen. One of our engineers related how a prior employer’s alternative to picking an analytics platform was to just put some fake KPIs on a dashboard. In this case, not making a decision resulted in actually delivering incorrect data to customers.
And there can be long term fallout from indecision, the kind that damages an organization. Infighting by different stakeholders about the choice of a platform wastes valuable time that could have been used to further develop an application, causes organizational chaos, and ultimately culminates in the loss of employees who move on to other jobs where they can actually build something.
My guess is that there are plenty of IT managers in enterprises who sidestep making commitments, but are lucky enough to have developers willing to shoulder the burden of their lack of decisions.
