Developers ... why do we insist on build vs buy?

I've recently been in this situation a couple of times - looking at either writing something myself to solve a problem, or purchase a product off the shelf to either integrate or run alongside my package.

The first time, when the project was something that I am solely involved in, I decided to go down the "do it yourself" route. This was more optimal for me as simply there was no time constraint, and no specific (immediate) financial cost to me putting in "just enough" functionality.

However just today I saw the other situation. A development team whereby they are looking to spend significant time on building functionality they could easily purchase pre-built from a third party vendor. And in this case, it would work out EXACTLY the same price as the estimated hours -- and this doesn't even include any "fudge factor", maintenance or the never ending tweaks that would be needed. And yet as developers we tend to do this so often - instead of realising that it is not always the best way, we push forward and insist that we can come up with something better.

Perhaps it is time that we stepped back and realised that it might actually not be a good idea to write this complete stack of support tools, and instead look to see what is there already? After all, we do purchase SQL Server and Windows Server ... or perhaps we should write our own replacements for these too ...

Comments (3) -

Phil Leggetter 12/06/2013 11:21:09

Maybe a better middle ground is to look at an open source component?



I'm sure this argument has been made a million times before, but I've never really thought trough it before.



Considerations are:



* The open source code is available for changes and contributions so developers can still develop on that component if they want to.

* You're not tied to some kind of subscription license in the same way you are when purchasing

* No risk of the owning company going "belly up"



What are the benefits of buying?



* The product should be "production quality"

* There should be defined levels of support

* There may be a planned roadmap of additional useful features/improvements



It all depends on the company making the decision.



If it were me I'd look at outsourcing functionality to API providers. Failing that I'd go with an open source solution. My final consideration would be to buy a component that provides the functionality I'm looking for. That's just my mindset.

Totally agree Phil; Open source is a great way to fill the void, and get a significant step up. The biggest problem I've had with many open source projects are either poor documentation, poor code, or they just get "dropped" (but as you say, at least in these cases you have the code!).



I've always been cautious about integrating any third party package with my stuff unless it's non-critical (i.e. if they go under, or start to price hike, I can cut it out quickly).

Phil Leggetter 12/06/2013 11:41:40

Andy - stale projects are most definitely a problem. As a company you need to pick them carefully e.g. for the Pusher Java client library I went with Java_WebSocket for the WebSocket client part, with a main factor being that it was being very actively developed and I'd been in touch with the main developer who had been very responsive.



If a company is to consider using an open source solution they should also consider donating to the developers of the project - maybe sponsoring it. Maybe putting some time aside for their own developers to improve it.



Good point about the code quality, test coverage and docs is also a factor when choosing a project. But, as with choosing a paid component there needs to be time spent doing some initial investigation.

Comments are closed