When is it NIH vs. being a sensible investment of time?

Question

So I'm sitting here playing catch up listening to Stack Overflow Podcast #20 and Joel is talking about the Excel guys at MS who wrote their own compiler to improve the performance of code that worked with pointers and it got me wondering

   when is it NIH versus being a sensible investment of time?

Given the situation back then that the current compiler performance was abysmal, I can see that selling this particular case to management was fairly simple given that you had a specific area of optimisation that you wanted to add.

But nowadays, can you imagine trying to go to management and saying you wanted time to rewrite gcc?

So how do people determine if an idea is worthwhile pursuing versus a "tilting at windmills" pursuit dripping in NIH syndrome?

I'm asking because we need to get some time allocated to improve some aspects of our operational platform. I'm interested in how to go "with cap in hand" to ask The Man for some time to be allocated to make improvements that most people know will definitely pay off in the future.

Edit: I forgot to highlight that we are a service company providing a platform for a major broadcaster. It is this platform that has grown organicaly over the last 15 years that needs some improvements. The provision of this service is our core business function.

Answer 1

Joel himself answered that, his best advice (which seems reasonable) is: If it's a core business function -- do it yourself, no matter what.

To that I could add, if it's not a core function, then you better have both economical and technical good reasons.

By the way, in what way the improvements you need time to do are covered by NIH?

Answer 2

We had a (vaguely) similar issue a few months ago, needing time to re-do something we had already built a different way to cater for instability of a downstream library. It seemed fairly easy to get it approved in the end - the app was suffering and I suppose they believed what we were saying.

PS

Probably stupid question and definitely not an answer, but whats NIH?

Answer 3

Memory allocation is a "core" requirement of all my software, and hence my business, but I wouldn't generally write my own allocator or collector.

Like everything else in engineering, there's a set of trade-offs in every case. These require experience to make, can be successfully handled in different ways, and can't be summarised in a blogger's sound-bite.

Try to get good at assessing the quality of 3rd-party stuff. log4net, which is what started this discussion around here is neglect-ware which has recently been dropped by some well-known projects (like nUnit). That would have been enough to put me off.

Answer 4

Vinko, it depends on your definition of "Core business function". If my business is Accounting, then calculating loan interest would quite definitely be a core business function, but it is certainly not unique to my company. Something "standard" like this should almost NEVER be written in-house.

If an available component does what I need, then I'll use it every time. If I have to do a lot of wrangling to make it work, then I might consider writing my own instead. You have to also take legal issues into account. There might be a perfectly good library that I can't use in my commercial application because of a viral license (GPL vs LGPL).

Answer 5

@Will Memory allocation is not a core business function for your business, unless you are writing embedded software or otherwise memory sensitive applications. Even then, if your business value is doing something else than being more memory efficient than the competition, it still wouldn't be a core business function. And if you are writing that kind of software and it differentiates itself through memory efficiency, how did you manage?

Yes of course you will always have to take care of the trade offs, as always, but that hardly adds any value to an answer. "It depends" is always a strictly correct answer, thus meaningless.

@Mel I agree. To me core business functions are functions relating to your main business that differentiate you from your competition. In your accounting example I doubt that the calculation you mention is a core asset of the accounting company, but something different like customer service or better knowledge of the law, or whatever.

And I also disagree, if you'll always use something that works even when that part of the application is supposedly your advantage (what will encourage people to use/buy your app.) then it stops being your advantage.

Let's just remember that competitive advantage is not always (almost never in the big scheme of things) due to software, and thus many many people can use existing components without risking their business.

Answer 6

It's all about competitive advantage.

The guys on the Excel team wrote their own compiler so they could make Excel much smaller than it otherwise would have been. This reduced their load-time and also the amount of memory the program used; it made their product better than the competition.

Similarly, Jeff could have used PhpBB to make this site but then he'd be just like the competition. He'd just be another dude with a forum. He wrote his own forum engine so that he could differentiate his site from the competition.

You should only deploy NIH where doing so gives you a clear competitive advantage or where doing so differentiates you from your competition.

Answer 7

This question is so timely, and its very interesting that the development of Excel inspired this question. We have an in-house project in which we needed some Excel functionality programmed into a PHP application. One developer has worked on this projected for over a year and a half. One does not realize how hard it is to rewrite Excel until you've tried it. Anyway, last January, I noticed that PHP had a PHPExcel library written for it by a 3rd party that is actively being developed and supported (it even supports Excel 2007). So did it completely make sense for us to reinvent Excel (especially considering the turn over of programmers in our department - this guy is leaving us next week).

To answer this question, you have to ask yourself if the additions or changes you want to make to your project's code will have a great exponential effect on the current feature set, or allow you to add more features in the future, with exponentially less time spent. You need to analyze and document the upside and downside effects that your code changes will have on the overall project, now and in the future. Also, consider if the changes will make it easier to maintain and contribute to future growth of the project - if so, that adds value to the application, especially if there is a possibility that you or others involved may be moving on to another job someday, or someone else may need to make changes, while you are busy on other projects.

By the way, "NIH" means Not-Invented-Here. See this link by Joel in his blog entry on the topic: In Defense of Not-Invented-Here Syndrome