9 commentsOne 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.
9 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Hi Stefan, nice post. I’d like to say a little bit more about not hacking existing modules/plugins/code. Your reasons still holds, but I also believe (according to my experience) that creating a module by altering another one is often more time-expensive than building it from scratch. That’s why I usually take into account only the first option when I need to implement some already-existing modules in a different way.
Anyway, about the post’s topic, I believe that having the broadest knowledge of the ‘building blocks (BBs)’ out there is one of the key ‘skills’ a professional must have.
Too many times I’ve seen people sticking at the same BB (framework, etc.) for doing everything, sometimes neglecting other tools on principle. I’ve also seen people choosing a particular tool just because it is trendy, even though it was absolutely inadequate or out of proportion to their job.
As for me, my philosophy has always been to know as much BBs as possible and choose the most suitable one(s) according to the project specifications and the client’s requirements.
Hi Stefan, interesting discussion. Everybody needs to do more BB analysis before they embark on creating something from scratch.
In my team we usually do a BB at the software component/module level and not so much at the application level. The risk of modifying an existing piece of software is that they normally tend to stick to a usability pattern that has been preset by the original developer and re-engineering it to do something else is time-expensive as Vincenzo mentioned. For my clients usability is a huge concern so doing anything within a mold causes more pain than gain (on a case-by-case basis).
Thanks for the insight into your BB process.
from scratch always wins
(with decent development process and people)
Thanks all for the comments.
I’ve had similar experiences in previous jobs where certain tools were chosen because “we always use it”. I don’t say it’s bad to be an expert in a single tool, but you should realize when the tool is not the right tool for the job. So yes, I completely agree with you.
Harvey: Aside from the BB on component/module basis, the application-wide check it still a smart move because sometimes tools are not very compatible so combining them would be useless. So first on application level, and then drill down to components/modules, is a smart move if you ask me :)
Steven: I highly disagree. That makes you reinvent the wheel every time. There are tons of tools and frameworks outthere that you can use out of the box for a lot of projects, and combined with some custom code may be the perfect solution. Doing everything from scratch takes needless time.
Hi Stefan, great post. But what about the option to buy? I though this was a post on the merits between buying off the shelf and DIY. It seems the post is more about the best way to approach a build solution.
In my experience, i’ve found that it’s usually pointless to build stuff like HR and Finance systems – probably better off buying a solution for that.
diagnostix: from my experience so far (but of course in essence, Ibuildings is a development shop) it rarely happens that you want to simply use an off-the-shelf solution. Often, there are specific requirements that can not (fully) be fulfilled by an off-the-shelf solution. so in the end, you may need to extend the off-the-shelf solution to fit all requirements.
Continuing the Discussion