Blog

The Tyranny of Now

As developers, our greatest challenge in all likelihood dealing with expectations of immediacy. Our business partners want results and they want them now. This often leads to sub-par architecture & development decisions riddled with tech debt.

This isn’t to say that the business decisions driving that are bad. Quite to the contrary they are often good. That said, tech debt is bad. Always. No Exceptions. However, it may be (and often is) beneficial to take on tech debt for financial gain. It turns out that just like the financial world, the trick is to make sure that the income generated from taking on the debt is sufficient to repay that debt at a later date with interest.

So how do we gauge when to act quickly and take on tech debt and when is it better to do things the Right Way™? How do we go about negotiating this with our business partners? Our bosses? Our fellow teammates? Well, that’s pretty damn hard.

Honest negotiation between parties and weighing the risk versus the reward is incredibly difficult. The two groups don’t share a lot of common ground which can make it incredibly difficult to have useful conversations. In general developers are often not well versed in the financial or marketing worlds and the business representatives are similarly not well versed in writing code. It is imperative for both parties to communicate their respective goals and concerns in a way that the other party can understand. Those in leadership positions need to facilitate this communication. Above all, the dialog must be in good faith, grounded in compassion and honesty.

In my experience there are recurring issues that are the wellspring for the tyranny of now. Many of these can become feedback loops. Most are the result of bad communication, dishonest communication, or entirely missing communication.

1. Problem: Communication is a one way street from business to IT.

   Solution: The process and culture must change. One way communication will always result in demands for the quickest turn around possible. IT must have a method of communicating concerns to their business peers who must be willing to listen and work towards a compromise.

2. Problem: Communication is a one way street from IT to business. This generally comes in the shape of someone in IT overriding all or a majority of business decisions. A lesser form of this is an IT member saying "I don’t know what Jane in marketing does" on a regular basis.

   Solution: The IT staff needs to pull their heads out of their asses. The business + IT = TEAM. You’re not going to have a whole lot of success if you insist on not working together.

3. Problem: Business decisions are often not grounded in good financial sense. When this happens, there is no increase in income to enable paying the debt back. This often leads to taking on more debt to try and make up ground and ever increasing pressure for quick results. A truly viscous circle as the developers will lose trust in their business partners.

   Solution: IT leadership must hold the business accountable for providing the business value before a feature is started. Once a feature is implemented, they must request the business to provide metrics on the success or failure of the feature. Features which do not provide value should be removed when possible as they only contribute to dead support weight slowing down the delivery of other features.

4. Problem: A feature request may provide value, but the value may not be significantly tied to immediate implementation. In this instance, the correct answer is to avoid a tactical solution geared towards speed of delivery and instead do things the right way. Despite this, the feature requestor wants the feature as soon as possible.

   Solution: IT leadership must hold the business accountable for providing the business value quantified over time to weigh the reward of short term versus long term solutions. This value must be taken into consideration when determining wether to proceed with a quick fix or a long term solution.

5. Problem: Business partners and/or IT leaders may have no intention of paying down the tech debt and are instead focused on maximizing short term profits. These individuals will always push for immediate results. This tends to align with job hoppers; individuals whose goal is to only make themselves look great for a couple years and hop up the ladder to their next gig looking like rock stars. Meanwhile those they leave behind are burdened with the tech debt they created.

   Solution: Don’t hire them. When vetting leadership candidates, do not just reach out to their most recent job but also the job before that. What kind of state did the candidate leave that employer in. If you have already hired an individual like this, fire them.

6. Problem: IT leadership may ignore the warnings of their developers about the amount of debt. This can be catastrophic as the continued accrual of tech debt will inevitably do serious harm to the team’s ability to meet demands. This back pressure will affect the business partners as their requests will take longer and longer to complete. Often times this will lead to a mistaken belief that the developers are either incompetent or lazy.

   Solution: This is likely the most difficult to solve and diagnose. Willful ignorance is an incurable disease. However, this one may not be the IT leader at all as much as a symptom of unreasonable business requests. Tread carefully and make sure this diagnosis is correct. If it is and you are an outside party try to facilitate communication between the leader and the developers. If you are a developer, make sure you are communicating your concerns (see below). If none of these work, it may be time to move on from this person.

7. Problem: The developers themselves are not without blame. IT leadership will only be able to heed their warnings about tech debt if the developers tell them about it.

   Solution: Developers must communicate with their IT leader. This cannot be a bitch session. The feedback needs to be measurable (e.g. this will take 2 developers four weeks to do correctly) and reinforced with impact (e.g. we won’t be able to implement feature X because we took shortcuts in feature Y the year before. We must first fix Y and then we can begin work on X). If communication to the business leaders is provided by an IT leader, this communication should be passed on to the business and taken into account as part of the risk verses reward analysis.

8. Problem: Often times, there is a tendency amongst some developers towards perfectionism. This can lead to a steadfast refusal to take on tech debt. This leads initially to longer implementations where significant financial benefits are likely missed. This in turn can further drive pressure on the business which will only reinforce the immediacy of their demands. This will escalate tensions, deteriorating the ability of the team to perform. Business leaders may seek to circumvent this developer leading to sub-optimal results and increased tech debt.

   Solution: This individual needs to be warned about their behavior. It is as important for members of IT to compromise as it is for business partners. Ideally the business is providing justification for their requests as that should alleviate some of the developer’s concerns and help them meet their peers halfway. Some developers will never change their viewpoint and may need to be tucked into a corner of the code where this attitude doesn’t cause significant issues. Other times, it may become necessary to let this individual go.