Funding a Software Product Line

The problem in most businesses is that there is a budget for project based development, but not for infrastructure investments across projects. Let's say project A will cost $100,000. Imagine that by putting an extra $20,000 of effort, you'll now be able to use that to deliver project B and project C later this year for $70k each instead instead of $100k each. Clearly you're saving $40k in development costs in the first year, but many organizations will be unable to realize those savings because all they'll see is an initial project going $20k over budget for no good reason. Surprisingly this is one of the most common issues when companies with suitable use cases finally try to adopt a Software Product Line based approach.

There are a few common patterns for handling this that have worked for companies in the past:

Funded Internal Project
One of the most common patterns is just to fund an internal project (for consulting firms) or an infrastructure project (for internal development). For internal teams this is pretty straightforward - there are usually infrastructure investments that are shared across projects anyway (most companies don't charge - say - the purchase of new developer laptops to a given project). This usually just requires a business case showing the likely cost savings and sign off from an appropriate level of management.

Consulting Companies
For consulting companies it's a little harder. The problem is that if they spend $20k to be able to deliver projects for $40k less, all they've done is cut down on their pipeline and lost $20k since they get no benefit from delivering projects more cheaply. The only exception to this is if you have a consulting firm that's running under capacity due to its inability to deliver projects cost effectively. Such a firm might choose to invest $20k in being able to close more deals.

Assuming they can't write it off as a sales expense, most consulting firms have to move to a model where they charge something for the reusable intellectual property in addition to their usual time/materials billing. The main issue then is coming up with an acceptable price point for the functionality in a world where more and more businesses are less comfortable paying for software (why pay $25k for that when I could get Drupal or OSCommerce or whatever for free?).

An alternative we use at SystemsForge is that we provide fixed bid development for certain classes of projects. That allows our clients to minimize risk (they know what they are going to get and what it is going to cost), it allows them to get a better solution at a lower price, and it allows us to make a better profit than simply billing on an hourly basis. The main issue with this approach is managing the risks and tensions inherent in fixed price/feature/timeframe development. The problems are usually solvable for sub $50k projects, but there are a lot of gotchas (you might want to check out one of my requirements/estimating presentations to get an idea of the issues we've found and addressed to date).

Unfunded Development
Sometimes, despite the best will, for political or other practical reasons, it's still not possible to fund the development of a Software Product Line. What's a developer to do? A good starting point is often to just start to develop small reusable assets. Maybe you start with cut and paste re-use between projects but then start to create little configuration tools for (say) generating your custom ant/maven build script. You might create a small web based wizard for generating project templates (or you could look into third party solutions like Spring Roo for Java projects or Grails in Groovy or Rails in Ruby which have similar capabilities).

You might also see if your company can start to use and contribute to OSS projects for the parts of the project that aren't real differentiators for your clients. That way you can both invest in a reusable asset and take advantage of the input of other developers for free.

Just Do It
If you're building at least 3-5 projects a year, sometimes it's best just to get started with a Software Product Line. Generally the best SPLs come from existing code bases anyway, so it's more a matter of systematizing the reuse of assets than a huge upfront project you'll have to undertake to get started.

Most companies can start to create re-usable asset repositories for elements of their projects and some kind of interface for intelligently reusing and versioning them in under a developer week, and if you can't afford even a week, just start off with a wiki and some shared files and on future projects use the time you save by (say) reusing instead of building a script to improve the SPL. Consider tracking it like any other project with a backlog and just pull stories whenever you get a few free hours and you'll be astonished how much you'll be able to build in a year!

Want to know more about the practical application of software product lines? There is a new conference devoted to the topic - from the team who brought you Code Generation. Check it out!