I believe that software development should be approached scientifically. Just as scientists research in a given area, like nuclear physics or molecular biology, software developers should be performing research in a particular area: your business's value streams. Just as scientists formulate hypotheses, perform experiments, and collect those results into knowledge that they then use to do further research, software development should do the same. Software development isn't just about creating features any more than scientific research is just about creating experiments: it's also about knowledge. Let me explain.

Most custom software development projects are large, expensive scientific experiments. But, generally, we don't see organizations communicating in those terms. You see, the hypothesis of one of those project-experiments is usually some variation of this:

If I had some software with <these features>, then I'd make more money than what I spend on the development of that software.

Owners, executives, and managers are unlikely to fund a project if the entire premise of it was a single scientific experiment that costs the entire project budget to execute. So, we hide this dirty little secret behind nice-sounding words like vision, experience, expertise, and opportunity. Projects are funded assuming that insight and expertise will override hard-to-predict factors like user behavior, market timing, economic trends, political climate, social media influence, the price of gasoline, internet speed, worldwide weather phenomena, and countless others. The truth is, we have very little actual knowledge about whether the software will be successful at the beginning, when funding decisions are getting made.

So, if we were to expand that unwritten software project hypothesis according to how projects generally get funded, it might look like this:

If I had some software with <this specific set of features>, then I'd make more money than what I spend on the development of that software. I believe that my combination of expertise, experience, intelligence, and insight has led me to the right set of features such that it will outweigh any missing information or hard-to-control factors in the success of this software development effort.

It says the quiet part out loud with a bit more precision, but, at its core, it's still a single, expensive experiment based on speculation and limited knowledge. A high-stakes bet. A bet that might not pay out. Yet this is often how projects get funded and executed.

Consider how much different it would be if projects were funded on creating value in a particular area and not on specific features? What if the project was a bunch of small, low-risk experiments instead of a single high-stakes bet? What if the hypotheses of the project were continued repetitions of:

I believe that <feature(s)> will generate <value> as measured by <method>, building upon what we learned in <previous experiment>.

Imagine if the first of these experiments could be completed with only 5% of the project's budget spent. Imagine if the project reached ROI with only 40% of the budget spent. Imagine how much easier it would be to add new, unforeseen features that weren't in the original plan. Imagine how easy it would be to eliminate unnecessary features or features that harm value. Imagine how much less risk there is. Imagine how much more of your project's budget would be spent generating value instead of just building features.

Healthy software development is scientific: a series of small experiments. Those experiments deliver value (of course) like, say, revenue. but they also create knowledge. That knowledge is the science of your business's value streams, and it's essential in choosing what software features to build in what order. Don't make bets: be scientific.