When developing solutions for our clients, we have a vast array of third-party tools we can use to rapidly and efficiently develop software. The kind of third-party tools I’m talking about today are the GUI widget libraries and base toolkits that provide a higher level of functionality, such as those offered by DevExpress and Infragistics for .NET GUI development, or even pluggable CMS systems like Drupal or DotNetNuke for web sites.
We strive to reuse whenever it makes sense, but when does it not make sense? This is a tricky issue I deal with a lot.
The first thing I consider is how well the third-party tool matches the need. Third-party widgets almost never meet the needs of the solution right out of the box. They often require extensions to meet our requirements, but more often than you might think, the third-party developer has been so over-enthusiastic in adding functionality to their offering which we don’t need, that a significant part of our job is disabling and hiding needless complexity from the user! We must always weight the costs in time to roll our own code versus the cost for adapting the third-party tool. Often, building up what we need from zero is more cost effective than extending out and chiseling down a third-party solution to just what we need – without even considering other factors.
The second thing I consider is support. When we roll our own, we know how it works. It is custom-fit for our purpose and has no unknowns. When we use a third-party, the code is a black-box. Even if they supply source code, who has time to make sense of their pasta explosion? We are at the mercy of their developers’ abilities and the responsiveness of their support team. I have been burned enough by this over the years that I weigh this part of the equation pretty heavily. When things go wrong after the project is complete, clients get really impatient — and rightfully so. Saving a week of development time by using a third party that costs you a week of the client waiting on a fix post-implementation is not a trade you want to make, not if you value your client relationships.
There are probably a dozen other little issues I consider on this, but the last big one is the potential legal issues. We have clients that don’t want open source. They don’t want to monkey with redistributing code or GPLs or what-have-you. If they allow third-party tools at all, they want a very clear license granting unlimited rights and ownership. So, part of the conversation I have with clients at the onset is:
“Are you willing to leverage third-party libraries in your solution? What if they require re-distribution of source or a license?”
They have their own reasons, but even when we have a third-party tool that is a perfect match, some clients rather pay us to build a custom module.
And, honestly, that is fine with me. As a developer, I must admit I am biased toward building a custom solution. It is far more fun to build new than to hack old. Its not just me, every real code monkey I’ve worked with would rather write a new thing than adapt an old thing. Never underestimate the huge multiplicative effect on productivity of a motivated hacker – that also has to be factored into decisions on third party tools. And that gets factored into our bid.
At the end of the day, it comes down to solving the problem within schedule and budget, and sometimes the decision on whether or not to go with third party tools is counter-intuitive.
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at firstname.lastname@example.org. You can also connect with us on Twitter, Facebook, or LinkedIn.