Build it yourself?
Robert Annett had a good post asking the question, “Do you need to build it yourself?” He states:
I’ve worked in many organisations and one thing that never ceases to amaze me is how often teams build unnecessary tools and frameworks … As a software/systems architect it’s your job to deliver value to the business you work for. Whenever someone suggests creating a bespoke tool ask yourself the following:
- Can I buy something to do this?
- Can I use or tailor an open source product?
- Can I use or create a template for a standard tool like Eclipse, Word or Excel?
I think that this is a challenge for corporate IT departments. I managed a frameworks team at a previous employer, and it’s extremely difficult to figure out where to invest your time. It was a continual game of guessing as to what things the vendors would add in the next release, what things would take off in open source community, and what things would be woefully underserved by third party products, whether open source/closed source or freeware/commercial products. It’s also not limited to low level frameworks, either, although the higher you go up toward business applications, the fewer choices there are and the more they cost.
Every company is going to be different with how they approach this problem, and a lot of it is dependent on company size. If there are IT resources to burn, you may be able to afford having a frameworks team, potentially even allowing developers to contribute to open source frameworks on company time. If IT resources are scarce, however, you have to balance the cost of a third party product and the cost of not having resources working on business solutions where custom coding is required.
I expect that to many of my readers, this is nothing new, but I do think that it a reminder now and then is good. Our responsibility is to deliver the best business solutions for appropriate costs, whether it is something off the shelf or something custom built. It is our job to be good corporate stewards and do our jobs wisely.
One question Annett may have missed:
* Has someone else in the company already built this tool? Are they one cubicle away?
There is a tendency to hand-off development projects to developers with little/no oversight as to how the solution is created. Given the general view “it’s easier to build new than to find out what already exists and work with that” it is little wonder that the wheel gets invented over and over.
Imagine how this will play out in the services world.
Great comment Rob. A key part of any effort that is associated with reuse is simply to raise awareness on what’s available in the first place.