One of the biggest struggles in any software development company is “Buy vs. Build”. How do you strike a balance between writing custom software and purchasing off-the-shelf solutions. This is something that is very hard and everyone gets it wrong every once in a while. In this article we will explore the way that Ibuildings approaches this issue, in the hopes that it helps others in getting it right more often.

At Ibuildings this decision is made early in the process. Talking to customers we either write or receive requirements and specifications for the application that we’re going to build. As soon as we know the general requirements, we can begin to look at what open source systems would fit the needs of the project. As more details of the system emerge and functional specification is written, it is possible to select the open source software to base the application on. Given the amount of good open source code available, we hardly ever write an application from scratch. Writing something from scratch wastes resources and causes frustrations because developers are constantly re-inventing the wheel (and realize they’re doing just that).

During the selection process, we don’t just consider the system we want to use as a base, but also research which plug-ins, modules, and add-ons that are available that fit the requirements of the project. Even though your foundation is strong, if you’d then have to take wood to build your window sills and have to bend metal yourself for your kitchen sink you’re doing something wrong. Don’t just look at the system you want to use as your foundation, but also check if there is standard add-ons you can use to build upon that.

As the selection process comes to a close, the end result is a system we are confident will help us build what the client wants. This base system can be a standard Content Management System, but can also be a component or full-stack application framework. At Ibuildings we have the luxury of having knowledge of a broad range of systems. This makes it easier to pick the right tool for the job. If you have limited knowledge of the tool that seems the best for the job, you will need to calculate some extra learning time into your project schedule.

As we move into the development phase of the project and the base system is set up, the development team starts selecting the standard modules available for our chosen system that fit the requirements of the project, or at least come close to fitting those requirements. When the standard module fulfills all requirements out of the box, they are installed and configured to fit the application. Often, however, standard modules won’t fulfill all of the requirements, or they implement it in a way that is not according to the specifications. In these cases, try to extend the existing module wherever possible to make it fit to our needs.

In some cases, the setup of the existing module does not allow for easy extending. In these cases, the development team must decide between two options:

  • Write the functionality from scratch
  • Alter the code of the standard module to fit our needs

The first option will take more time. Sometimes however, this is the best option available.

The second option is the one that needs to be avoided where possible. It is very bad practice to hack in the existing code of a module. By doing that, you will make it much harder to upgrade the individual module to a newer version should a bug fix or even security fix be released. There are cases though where this is a necessity.

There is no single option that can be recommended in these situations. It is important to look at what needs to be done to make something fit. You need to look at both options carefully and decide which would take less time. When you write a feature from scratch you are responsible for all maintenance of that code, therefore modifying existing code and losing future upgrade paths may be the better option if it takes less time than writing from scratch.

Lastly, there is of course the possibility that there is no standard module available for a requirement in the project. The more complex the application is the better the chance that you will have to write custom modules. It is certainly not wrong to write code from scratch, as long as you have taken the time to research if there is an existing solution that fits your needs. The one thing you don’t want is to reinvent the wheel, especially for complex code.

One important thing to note is that whichever tool is chosen, developers should stick to the coding guidelines of that tool so that the code integrates into the system as much as possible. This keeps the code readable and ensures that other developers used to working with the tool can more easily read the code.

Whenever possible, try to reuse existing code, whether it’s your own existing code or open source standard modules. Writing functionality from scratch should be limited as much as possible to those parts of an application that are too complex or unique to use standard modules for.