How can I tackle 'profoundly found elsewhere' syndrome (inverse of NIH)?

Question

How can I encourage colleagues to embrace small-scale innovation within our team(s), in order to get things done quicker and to encourage skills development?

(the term 'profoundly found elsewhere' comes from Wikipedia, although it is scarcely used anywhere else apart from a reference to Proctor & Gamble)

I've worked in both environments where there is a strong opposition to software which hasn't been developed in-house (usually because there's a large community of developers), and more recently (with far fewer central developers) where off-the-shelf products are far more favoured for the usual reasons: maintenance, total cost over product lifecycle, risk management and so on.

I think the off the shelf argument works in the majority of cases for the majority of users, even though as a developer the product never quite does what I'd like it to do. However, in some cases there are clear gaps where the market isn't able to provide specifically what we would need, or at least it isn't able to without charging astronomical consultancy rates for a bespoke solution. These can be small web applications which provide a short-term solution to a particular need in one specific department, or could be larger developments that have the potential to serve a wider audience, both across the organisation and into external markets.

The problem is that while development of these applications would be incredibly cheap in terms of developer hours, and delivered very quickly without the need for glacial consultation, the proposal usually falls flat because of risk:

• 'Who'll maintain the project tracker that hasn't had any maintenance for the past 7 years while you're on holiday for 2 weeks?'
• 'What if one of our systems changes and the connector breaks?'
• 'How can you guarantee it's secure/better/faster/cheaper/holier than Company X's?'

With one developer behind these little projects, the answers are invariably:

• 'Nobody, but...'
• 'It will break, just like any other application would...'
• 'I, uh...'

How can I better answer these questions and encourage people to take a little risk in order to stimulate creativity and fast-paced, short-lifecycle development instead of using that 6 months to consult about what tender process we might use?

Answer 1

There is no guarantee that an off-the-shelf app will last or be maintained in the future either.

It's a devils bargain either way. Companies are right to be leery of in house applications; I've worked on some of the most horrible in house apps you can imagine, the output of 1 or 2 hero coders working in languages that no one uses, developed over a span of 2 or more decades. Applications which are a constant drain of resources, but would cost far too much to replace.

So companies seek the assurance of an "Off the Shelf" product, produced by a company that (hopefully) will be around for a while, and (hopefully) will get around to implementing features that are needed.

Which is better? Neither. They both have problems.

Be especially wary of short development cycles though. That's where all the worst stuff comes from. Those processes and meetings; those are there to be sure that the code is designed to be maintainable, and not the product of 1 schmuck with a bug in his ear. Those things that get tossed off in a weekend are brittle, linger forever, and are extremely difficult to maintain.

Answer 2

First of all, the arguments against creating in-house utilities are valid in general.

If you want to counter those arguments, you will need to accept that they are often correct and demonstrate why the benefit outweighs those very real risks in a given situation, for a given project.

The company generally pays developer's to solve business problems, not to create utilities. You will need to clearly show how an investment of X dollars (they are thinking in terms of dollars, not hours) will lead to a productivity increase that warrants that investment, given the risks you correctly outline.

To sum it up:

• Accept that the arguments are often valid
• Be very specific about why this particular project delivers enough value, at low enough risk, to take people away from solving immediate business problems.