It’s tempting to push projects out the door, to woo and impress colleagues and supervisors, but the stark truth is that even the smallest projects s

The hidden cost of speed

submited by
Style Pass
2024-09-05 18:30:07

It’s tempting to push projects out the door, to woo and impress colleagues and supervisors, but the stark truth is that even the smallest projects should have proper review periods.

There’s nothing quite like the rush of starting a new job and whipping out projects, particularly at an organization where technology is not generally prioritized. Management falls head over heels for your ability to stand up and deploy marketing requests, and as you crank out project after project, it seems like you’re going straight to the top.

Then one fateful day, an urgent request comes in: “We have a real opportunity to capture some immediate sales, but we don’t have an avenue for tagging and remarketing to these leads. What can you stand up before the week’s end, in time for the conference? Surely, you can get something set up?” They stare back at you on a Teams call while you archetype an API service to accommodate the traffic. With your coworkers depending on you and your hubris swollen from recent victories, you make a choice. To meet the deadline, you turn to another language or framework to stand this up, because you are a go-getter and a wizard. As you quickly deploy the dirty codebase, and as your accolades are sung from on high, you think, “I’ll lace this up with our core later. They needed it now—and I did it.” You have reached peak developer-nirvana; none dare question your skill.

Months later, marketing and management requests have continued non-stop and (of course) you’ve had no time to lace everything up. You think back to that fateful decision to implement a quick fix, not anticipating that the organization would utilize it on a daily basis, requiring constant updates for every unique sales avenue. In your haste, you built a system that is functionally not operable within the rest of the ecosystem—and you are now subject to that decision. As the requests take longer and longer to work, questions start to arise: “Is our developer losing his touch? Why is this taking so long when it used to take minutes?” Instead of articulating the issues or communicating the challenges, you keep applying patches and quick fixes. As the choices you’ve made in your haste pile up into a series of compounding issues, your turnaround time slows, but the requests for new projects don’t. 

Leave a Comment