Five Types of Features

When you're developing a new web application, each of the features within the use cases can be broken down into one of five broad classes: "rocket science", "lab experiment", "new to me", "with a twist” and "here we go again”. In this posting I want to look at the differences between each type of feature and how that could influence the estimating, specification and development of your web applications . . .

Rocket Science
Rocket science is fundamentally hard. Maybe you’re developing a unique algorithm for figuring out what movies someone will like based on their iPod playlist or maybe you’re working out how to tag videos automatically using facial recognition software and a database of driver license photos. With rocket science, you’re doing something that is new to both you and the general development community. Sure, some researchers or companies might have worked on the problem, but there are no widely agreed upon approaches or algorithms for solving the problem.

Rocket science is one of the reasons that projects go wildly over budget and timeframe. The reason that rocket science projects often go over estimate is because there is no reliable way to estimate rocket science – it is a futile endeavor. Rocket science takes as long as it takes. The fundamental nature of rocket science is that you don’t know when (or sometimes even if) you’ll complete the project, and no amount of estimating or project planning meetings will solve the fact that nobody knows how long it will take to solve an unsolved problem. Rocket science projects have an almost unlimited risk profile with the possibility of a project going ten or twenty times over budget or even being found to be either fundamentally or commercially insoluble.

It is theoretically possible to fixed bid/fixed scope rocket science projects, but a traditional Agile approach usually makes more sense as it allows you to modify the requirements as you learn more about the solution space to maximize the chance of providing something of valuable in a reasonable amount of time. It is important that clients (whether internal or eternal) understand what parts of a project are rocket science. If they don’t think twice about removing the feature, then you’ve not been graphic enough about the challenges. Rocket science is the "dragons lie here” of the software development world, with unforeseeable dangers because you’re sailing off of the end of the map. Developing "rocket science’ has almost nothing in common with developing regular software and needs to be managed differently.

Lab Experiment
A lab experiment is a special type of Rocket Science where non-functional requirements are the main risk factor. "I want a system that does something but it MUST handle 2000 concurrent users and have a latency that doesn’t exceed 2.3 seconds for local users on a 100Mbps network in the same building." With a lab experiment, meeting the functional requirements may be straightforward, but meeting the non-functional requirements could take an indeterminate number of rewrites using different algorithms, architectures or even programming languages. As with Rocket Science, the potential risk of project overruns or finding the problem to be fundamental or commercially insoluble is substantial.

New to Me
In "new to me”, you’re solving a problem that others have solved but that nobody on your development team has experience of. If you have one developer who has only ever built content management systems, then a shopping cart is a "new to me” project.

With "new to me” projects, there are well proven algorithms, but the developer has to learn and internalize them. There are also usually many "gotchas” that the developer was unfamiliar with so the initial specification will usually miss out on some key distinctions leading to problems on fixed bid/fixed scope projects.

I have found that most "new to me” projects can run 2-5 times over initially estimated budget. Typically a good paid discovery phase will help to keep the overrun to the low end by removing most of the specification risk and leaving just the implementation/learning risk. For a consulting firm, I’d caution against doing a "new to me” project without either a paid discovery phase or a generous multiple of the time estimate when bidding.

With a Twist
Luckily, the vast majority of web applications built are "with a twist”. Typically someone is looking for another social networking site or cms or newsletter system or shopping cart. It may have different business rules, workflows, a slightly different object model, maybe some additional database tables, some different object attributes and some unique reports, but fundamentally you’re working on a class of problems that you’ve solved before.

In with a twist, there is always the possibility of a surprise: "but of course I assumed it would automatically pull the tax rates from all of the states and know the difference between taxable and non-taxable items in each state”. On the whole, though, if you have a good specification process you can estimate "with a twist” projects fairly accurately – even without a paid discovery phase (for those of us working with SMEs that usually don’t have that luxury). With a twist projects may go a little over or under budget, but it usually all comes out in the wash if you do enough projects a year.

Here we Go Again
With "here we go again” projects, you can often re-implement an existing system – pretty much as is. I typically find that we use here we go again code for clients who don’t really care about a feature. They may want a highly customized checkout process, but they just need a simple newsletter system, so they’ll go with our standard code for the newsletter, saving us all a lot of time and trouble in specifying a system from scratch when we already have something that meets their needs.

How do I Use These Ideas?
Well, at SystemsForge, we classify all features internally using one of these five classifications. We try to keep the vast majority of our projects focused on "with a twist” and "here we go again” features. In that way we know that the majority of projects will be easy to estimate and implement, and we are creating a comprehensive Software Product Line solution for automating the specification and generation of these classes of feature so we will be able to offer them with a price point, feature set and timeline that can’t be matched using manual development processes (even offshore) and with a flexibility that can’t be matched with pre-built code.

In terms of "New to Us”, if it is a feature we believe will be in widespread demand, we’ll often bid it at what it would cost if we’d already developed it (typically a small fraction of the development cost) and we treat the rest of the effort as R&D for expanding our Software Product Line to include a new class of features. If we don’t see the potential in the feature, we’ll just charge a reasonable estimate given the risks we know we’ll encounter so that our new to us projects average out profitably even without a paid discovery phase. We try to manage the amount of "new to us” work at any given time and to schedule the time to deal with the problems we know are going to arise.

In terms of rocket science and lab experiments, we try to avoid such features and where a client absolutely requires them, we will not provide a fixed bid/fixed scope without a paid discovery phase. In the future I think we’re going to outsource ALL such projects to see if anyone else can make money off of them at the kind of price points our resellers can stomach – we certainly can’t!

So, do you classify features when estimating projects? What classifications or heuristics have your found to be of help - especially with smaller clients who are less sophisticated about the process of software development?