As a technical professional, one of the most repeated phrases you’ve probably heard is "don't reinvent the wheel." Every time you’ve been tempted to write your custom library or to experiment with creating a new implementation for a business solution, a voice inside your inner technical conscience is most likely telling you not to do that. On the other hand, there’s something attractive about playing with something new—challenging yourself or testing to see if you can create something better then what’s already out there is a constant temptation.
And it’s not completely accurate to assert that we’ve never reinvented the wheel. As a matter of fact, we have reinvented the wheel hundreds of times throughout history. The tricky thing—the thing that’s constantly on your average developer or architect’s mind—is this: when should I push forward and try to do new things, and when should I just work with what’s already there?
Time-to-Market Constraints
There are plenty of factors that will determine whether you should innovate or not when you’re faced with a particular problem—but perhaps the most important factor is speed. One of the main reasons why we have collectively developed an ecosystem of libraries, tools, and software solutions is because we want (and need) to produce and use software with reliable speed. The competitive nature of our modern world has created tremendous pressure to produce more in less time, and relying on reusable code is one of the most consistent ways to make that possible. The evolution of the cloud and the use of common repositories has promoted the reusability of code in the shape of libraries, frameworks, components, and Software-as-a-Service solutions like never before.
This means that whatever time-to-market constraints your project may have need to be foundational considerations. The existence of a deadline could restrict your ability to innovate because putting the release date in jeopardy because you wanted to have your own version of a grid component is not an option.
Subject Matter Expertise
Another element to consider is the level of experience, the functional knowledge, and the technical expertise that you and your development team may have in the area of innovation.
Your ability to create a better (and successful) artifact is directly proportional to your expertise on the topic.
One of the most common arguments against developing your own implementation is that the industry libraries are "stable," i.e. they’re solid and tested. But that’s not completely accurate. Even the most long-lived library or product had to come from humble beginnings, and if you explore its history most of our base software comes from creating new releases as a vulnerability or a performance improvement is added. Obviously, your library probably does not enjoy the millions of reviewers, users, and daily tests that bolster the commonly used libraries—but that doesn’t mean that with some expertise you can’t produce something better, or at least find an interesting new approach to the problem.
Can you imagine the Gang of Four asking themselves: "Why bother creating another new software development methodology?" Or Linus Torvalds thinking, “It’s not worth working on another version control system?” A real innovator is always questioning the status quo and wondering whether there’s a better way of doing things. But, you need a deep understanding of the issue and a lot of experience in your area before you can even answer those basic questions.
This is not to say that companies with limited cloud experience should never try to think outside the box or do something new and innovative. Just that if you determine the standard, tried-and-true way of doing things isn’t the best option for your needs, you’ll need to integrate that expertise and experience. If you can’t make that happen in-house, you’ll have to look elsewhere.
Customized Software Needs
So far, it might seem like we’re suggesting that innovation in the modern marketplace is hard to justify in light of time-to-market pressures and skills shortages. But don’t be fooled—if your company has specific needs that require a customized approach, the existing libraries and frameworks might not be a good fit. If you’re using an existing library or a framework, have to adapt your own needs to the functionality and capacities it already offers. Most of the libraries and frameworks are generic enough to satisfy the most common needs, but when we’re talking about solution software it’s sometimes difficult to find one framework that covers all our needs. In these cases, it’s easy to end up with a Frankenstein of applications tied by a weak integration mechanism.
If your business, your process, your vision of your software is specific enough that it requires customization, reusing will be more costly and more traumatic than investing in the creation of something new.
Budget
Similar to the time to market, budget limitations are an important constraint when we need to decide between innovating or consuming. Innovation does not come for free: you need to have the right team, with the right expertise level, and enough budget to cover it for the time that’s required to achieve something. In scenarios with a limited budget, the best shot is to be conformed with reusing an existing solution and focusing your energy and resources to make it work under your real-world constraints.
Of course, cost can be a tricky thing to grapple with. Above we said that if your use case is specific enough, the costs will pile up if you try to fit square pegs into round holes by reusing standard libraries. This means that it’s not enough to say, “My budget is limited, so I need to avoid rocking the boat.” You need to take a holistic approach and think about your particular business case and its larger-scale financial ramifications. Sometimes innovation, while more complex, also has a better chance of positive ROI.
Expert Teams to the Rescue
If the dilemma we’re describing sounds familiar, you’re not alone. This is a choice that most businesses have to grapple with at one time or another—and it can involve a lot of unknowns: How will you ensure performance, security, and scalability? What criteria will you use to make decisions over the course of the project? Who will lead your internal teams as they potentially grapple with new ecosystems and technologies with which they’re not familiar? If you decide to innovate, you’ll need strong answers to those questions and more.
But, you don’t have to come up with those answers alone. Even at the early stages, you can consult with experts to help you understand whether you should be reinventing the wheel or not—and who can help you through each step of the process if you decide you need a custom-tailored solution to your particular business case.
This outside expert should have experience in multiple different ecosystems and war stories about related projects that have overcome challenges to ultimately achieve ROI. Ideally, after consulting on the relative merits, challenges, and costs of developing an innovative solution for your business case, they’d be able to provide you with a scalable, flexible team of allies that could get the job done—either doing the bulk of the work themselves or supporting your team through new processes and new environments. This team should know all about the security implications of, say, a particular cloud configuration, what factors will most impact performance, and, ideally, how different ways of customizing your deployment can impact your costs.
You don’t need to be Google or Microsoft to break the mold and do things in a new and better way. You just need the right knowledge and the right support—both of which you can get from the right managed services provider.
Learn More About Intertec’s Software Engineering and Support Services
Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
