Imagine you’re a software developer for a company. One day while at work you look upward and see a leak in the ceiling. Being very handy with a wrench, you push the tile out of the way and fix the leak. Easy, right? A few days later, you see another leak. No problem. You do the same thing. The next day you smell a weird, mildewy smell. You cut into the drywall and fix the mold problem even though it takes you three days. After that, your boss asks if you can do anything about the clogged toilet down the hall. Week after next you’re fixing a broken faucet in the employee break room. A month later you find out you’ve been fired because you missed the deadline for an important employee facing project but at least all the plumbing in your now former job is fine.
This seems like a weird anecdote but there’s a point: Your job is supporting projects that deliver revenue. Anything that stands in the way of that is a distraction and should be avoided.
The example I used may seem nonsensical but I chose plumbing because it refers to infrastructure. If this scenario happened in the real world, most IT personnel would say, “Call the facilities team and open a ticket to have this fixed” and the implication would be that you should delegate this work to a professional who gets paid to do such things leaving you free to work on the things that you are being paid to do.
Buy vs. Build
When it comes to IT itself, engineers sometimes forget this and it often leads to bad outcomes. Consider this: Let’s say we have an engineer who hears his boss talking about buying a piece of software to automate an important business task. “Why spend money doing that?” our engineer says. “I can write a few scripts that can do that in ten minutes and save the company money!”
Let us break down why the engineer should really think about this carefully.
- Support – Even if our engineer loves his job, he doesn’t want to get called in the middle of the night when his cobbled-together solution breaks. As someone who spent years in engineering, I can tell you that custom scripts love breaking as you’re boarding a plane, unwrapping birthday presents, or about to sit down to an anniversary dinner. Not cool.
- Extensibility – Rarely do you write a script or a program where it works exactly as you envisioned the first time out. You’ll constantly want to modify or extend it and if it’s used by others, then they likely will want the same thing.
- More Incidents – Soluitons that are quickly put together to solve a single problem rarely go through a proper software development lifecycle. Your users are going to use your software in ways you don’t expect or it’s possible that you didn’t engineer your solution to properly account for all use cases.
- Cost – The engineer whips up a solution to save money but are such solutions really cost effective? Homegrown solutions are often not commented well or written poorly. If you leave the company, how easily can someone else follow what you wrote? Do you have adequate documentation? To an engineer, software can seem costly but to a VP or C-level executive with a better big-picture view of the organization, a commerically viable solution may be the more economically viable choice.
- Ownership – As IT folks, most of us like to tinker to satisfy intellectual curiosity but in many companies if you write something, you end up “owning” that solution even if you change roles or responsibilities. If your code ends up in production and you leave your tech role for a sales one … guess what? If there’s a production outage you’re still going to be called.
- Ego – Most of the time, we as IT pros want to show our superiors how smart we are. “I can do it!” sounds great but you run the risk of actually demonstrating the opposite by implementing a one-off solution that’s harder to support than an off-the-shelf solution. A true professional knows how to demonstrate big picture thinking and if you’re trying to encumber yourself with a homegrown solution needlessly then this is a very short-sighted solution. Just because you cando something doesn’t mean you necessarily should do something.
- Long-term Viability – Many times companies that encourage a write-your-own mentality find themselves in a predicament when the authors of such solutions leave the company. No one stays at a company forever and it’s very likely any solution you throw together will probably outlast you.
- Operational Maturity – Most organizations require solutions that can be supported by front-line personnel. Do you have adequate diagrams, documentation, and training materials? Do you update them every time you modify the software?
One-off versus Off-the-Shelf
The first thing thing the engineer should keep in mind is “How does this help me protect my revenue generator?” Time is finite. Your business has needs that only you can provide due to your deep knowledge of your business processes. Writing your own solution should be a last resort and not your first choice.
The next thing the engineer should consider is who is the leader in the space of the solution being proposed? Are we considering an offering from that vendor? Can we evaluate solutions from several industry recognized leaders?
Set up a bake off between several products. Volunteer to evaluate potential solutions. Write up your findings and present them to management and help them make an informed decision on the best way to proceed. This demonstrates responsible, big-picture thinking and is proactive and not reactive in nature.
At Sovereign Systems we write software that integrates vRealize Automation with your existing hardware and software solutions as part of our cloud management platform offering. We see potential customers make the mistake of trying to write their own proprietary solutions and we want to help them avoid the potential problems associated with that effort. We know how difficult and time consuming that process is because that’s what we do for a living. We can take that burden off of you and let you get back to the things you do best.
While we can take care of your virtualized plumbing, we can’t fix actual leaky pipes. Sorry.