Becoming agile

Agile, through the storms

A piece of cake. A huge piece of NIH cake

This is so tempting to start something afresh, something that only we will use, so it fits our needs like a glove.

It is so tempting because it seems so easy to develop exactly what we need – it must be a piece of cake to custom build it for us.

And of course what exists out there does not serve the purpose well enough, simply because it was NIH – Not Invented Here.

Image by http://www.flickr.com/photos/rabanito/

So here are ten reasons NOT to develop internally what exists off the shelf:

1. It is already tested by more customers

2. You enjoy from features you didn’t think of; you will enjoy future features you cannot imagine today

3. You are good at what you do business wise. So why try to become proficient in something other organizations are already experts in?

4. Conversely, by investing in existing tools you produce less of what you are uniquely good at

5. Once you deploy your tool you will need to maintain it, making even less of what you are good at

6. When you or the market evolve you will need to expand also the tool – what tool providers do anyway for their own survival

7. Changing the tool becomes much harder. For starters, the tool will be someone’s “baby”. You might also find that you need to lay off really good people to replace it, turning decision making harder still.

8. People always blame tools. Always. It is easier to defend a Rolls Royce or a Chevy than it is to defend a home made cart

9. Some tools (not yours!) are crap for real. It is easier for someone to admit that they’ve bought a piece of crap than to admit that they are making crap.

10. Think twice and thrice before you reinvent the wheel. If you are already making the Rolls Royce of your business, why service it with second grade tools?

What is your view? Are you developing tools that are commercially available?

Advertisements

Single Post Navigation

8 thoughts on “A piece of cake. A huge piece of NIH cake

  1. Reason 11 – Peace of Mind. I had a project a few years back where the business owner changed mid-stream. The old customer wanted something completely his own, but the new customer had worked with a commercial package in his last position and had loved it. The new customer, for whatever reason, wouldn’t cancel the project, but made my life very difficult continually complaining about the costs (which were within, not outside the range of the estimate). Needless to say, it was not a project that I would have missed had it been terminated.

    • Very true, Gene.
      Taking your point above and expanding my point on people always complaining on tools: It is hard to distinguish between genuine flaws in the software, and complains that originate from using this business unit as a scapegoat for various dysfunctions of the organisation (non-business unit may be more descriptive in many such cases)

  2. Bhaskar on said:

    I am partly agree with your points use developer tools which are available open-source and commercially. But sometimes we need to develop own internal tools which are wrapped on API or SDK which are not available completely. Sometimes, Cost of adapting commercial tool is too expensive in terms of money,effort then recreate part of the functionality for business requirements. For example, Instead of directly use cloud management tools(like rightscale) use ~500 lines of wrap logic on Fabric API.

    • Bhaskar, I agree with your comment.
      I am not “religious” on this one way or another. However, the guiding rule, in my view, should be that you should use what already exists.
      Note, that you are also adding the notion of extending an existing product offering to do what you would like it to do.
      This is even more relevant when open-source software is involved, as it provides opportunity to extend the opensource-offering (contributing to the greater good) as well as having your contribution tested and potentially extended by a greater set of users.
      I recommend reading about the Beekeeper model here: http://wiki.pentaho.com/display/BEEKEEPER/3.+The+Beekeeper+Model to learn about the potential of such model
      Thanks for joining the discussion!

  3. Why invent if you could contribute :-9

  4. Pingback: A piece of cake. A huge piece of NIH cake - Project Management, Email Management, Agile Productivity Tools - quickfocus.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: