During my career I’ve come from a technical background to a more strategic position and picked up several memorable lessons along the way. One of those is especially relevant to me in my current role where I have to decide on pursuing a short-term fix (while pursuing the long-term solution) or have the disciple to go the long-term route without a workaround. I’m personally biased towards the short-term fix, so it’s been a good lesson that has saved me trouble as my role becomes more strategic. Many people with a technical background are familiar with one of these two scenarios when supporting internal operational tasks.
- You have a deadline to deliver a solution, but the amount of time to have “the right” team deliver it is far beyond your project’s deadline.
- You have an open source tool that handles most of your needs. However, great business value can be added with a few (today) tweaks to the tool’s code.
These two scenarios represent what I have experienced as the two biggest drivers of this dilemma of customized code that can potentially provide critical business value and separate our organization from the competition. However, on the other side of this two-edged sword, these customized code solutions have a high level of associated risk of falling into mismanagement, presenting security risks, or locking you into your own forked version and losing the benefits of updates provided by the larger, original code stream. As an engineer at heart, I want to explore and identify several data points to help me (and hopefully you) better answer the question: “Should I invest in custom code, or should I justify a longer-term solution to my management and get deadlines pushed?”. Let’s dive into each of these two categories to investigate and see if we can identify clear decision indicators and maybe some best practices. more “When does “a little code” become “a lot of trouble””