Every software project starts with multiple choices made by stakeholders and the development team. One of these choices - and a very important one - is the choice of the overall technical approach to building the software. Nearly any application can be built from the ground up or on top of ready-to-use open-source components, and the choice of the path to follow depends on a combination of factors. In this short article, we will take a look at the pros and cons of these approaches to developing software.
Building from scratch
From the first glance, the boilerplate approach seems to be full of advantages. It is adored by developers, as they always want to have things their way and re-use as little of anything as humanly possible. It is appreciated by customers, as they love to own all of their code. It is met with enthusiasm by support managers, QA people and many other people who like working with a solid, homogeneous product. For the majority of people, applications built completely from the ground up look more “professional” and “bespoke”, and this is partially right - given, however, that the code quality is really high, that proper architectural decisions were made, and that the necessary quality assurance procedures are in place.
At the very least, building a product from scratch offers the following advantages:
- Full IP ownership - an important factors for large companies and startups alike
- Ease of support and maintenance - a product with the same code structure, classes, methods and such is naturally easier to maintain
- Detailed documentation is available for the entire solution, not just its custom parts
- Consistency of coding standards across the solution
- Independence from third parties in building and maintaining the product - if a solution relies on external component that can be rendered useless or unstable by a unexpected update that is out of your control, it’s a potential risk
- Increased effectiveness of test automation and potentially better test coverage
Despite the clear benefits of building a fully custom solution, it obviously requires a lot more time and effort. You start with a substantial phase of business analysis and discovery, then design the architecture of the future product, trying to make it as robust and scalable as possible, then add some flesh to the skeleton by developing features and modules, even the most basic ones. All of this results in a longer timeline, a potentially larger team and higher investments in the project.
Using ready components or products
The degree to which a project can benefit from using ready components can vary broadly. It could be a set of UI controls, specialized libraries or entire subsystems. The ultimate case is the customization of a third-party product, such as a CMS, to the customer’s needs. This approach is fully justified is the following cases:
- The product is intended for internal use and is not for resale
- The timeline is very aggressive
- A third-party component (or set of components) offer unique functionality that is hard (if at all possible) to recreate within a reasonable period of time
- Development resources are limited
- The functionality of the solution being developed nearly matches that of an already available open-source product, making it economically unreasonable to develop from scratch
As a rule, every product uses some third-party components and 100% custom applications are hard to find, unless they are extremely small or built for a very particular, unique area of application. If the goal is to develop quickly and with as little overhead as possible, ready components or products provide the shortest route from A to B. Some projects, such as relatively small corporate sites or even enterprise portals, are nearly always built on top of a third-party CMS (content management system), customized, branded and released a lot faster than they would if they were based on a custom framework.
Perils of code reuse
Talking about code reuse, we should not forget about the difference between using licensed open-source components and using code from previously completed commercial projects. The latter is the property of respective customers and the very practice of copying such code to a new project is a severe violation of contract terms. Unfortunately, inexperienced and immature outsourcing companies may occasionally do just that, putting their customers and themselves at great risk of losing money and reputation.
Cortlex has a zero-tolerance policy on IP-related violations and treats the property rights of its customers with utmost respect. We never reuse any of the code written within the company, always discuss the use of third-party components with the customer and explicitly include our licensing fees, if any, in our invoices. With Cortlex, you can rest assured that the only things that may be replicated are an efficient architectural approach and the overall success of the project.
Today, programs are no longer “written” or “programmed”. The developers of today “build” solutions from the bricks and blocks that they find to be most appropriate. If you are building a product with unique functional and non-functional characteristics, it may make sense to spend extra time to build a brick factory and eventually end up with a one-of-a-kind application free of any license restrictions. If you are focused on getting the job done and don’t mind taking a few shortcuts, there is no shame in avoiding the re-invention of the wheel and using some tried-and-tested components in your project - as long as they are integrated with the core of the application the right way, are architecturally in line with the rest of the solution, and do not hamper future maintenance and customization.
As your software development partner, Cortlex is always ready to advise on the best development strategy and the inclusion of third-party components into the scope of the project. We know how to make time- and money-saving shortcuts without compromising on quality and will be happy to share this information with you.