Geomorphology and Software

We know that the surfaces of the Earth change slowly over time. Tectonic plates shift, creating mountains; volcanic activity creates new islands and makes existing islands larger. Geomorphology is the study these processes: how landforms come in to being, evolve, or disappear.

Islands and continents are useful things. We live our lives on them, and we build our homes on them. I often get the sense that we play by the same rules in software: the changing landscape tells us where (and what) we can build.

Consider this description of Structured Programming methodologies from Scott Rosenberg's Dreaming in code.

[...] Its broader imperative -- that "each program layer is to be understood all by itself" -- has driven one innovation after another in subsequent decades as programmers have devised new ways to isolate, "modularize," and "encapsulate" the moving parts of software from one another (with the dream of reusable Lego components as its ultimate grail). But like each of those innovations to come, structured programming didn't help perfect the software of its day; instead, it laid a solid foundation for more ambitious software to come, and those programs would find new ways to fail that structured programming couldn't imagine.

The emphasis above is mine. Also, let me not forget to mention that I'm a huge fan of this book; I feel like I've gotten a tremendous amount out of it.

So then software industry innovations -- technologies, tools, practices -- are like Earth-shaping events: they allow industry professionals to live and build structures where previously that was not possible. I think we can describe in better detail, moreover, why this would be the case.

Normally when we scope a new software project or the next iteration of an existing project, consciously or unconsciously we conduct a form of analysis something like the following:

1. Compile a list of proposed features
2. Estimate both the Business Value and Effort (or Cost) of each feature; compare the two values to arrive at a ratio of business-value-to-effort
3. Features with the highest business-value-to-effort ratio get prioritized (these are commonly known as "low hanging fruit"); the better the ratio, the earlier in the schedule (in terms of phases or cycles) a feature gets placed
4. Features that have less Business Value than Effort associated with them don't go in the schedule at all

That last point (#4) shows where the map ends: beyond that point, there's no more land to stand or build upon. Better tools and development practices change the ratios, and suddenly a feature that was too expensive to build comes within reach.

Look no further than ebay for a shining example of how these forces shape the landscape of opportunity. It wasn't illegal, before personal computers and rise of the Internet, to create a massive, international marketplace for millions of heterogeneous items under $50; but it was economically infeasible. The cost of tracking all those small transactions by hand would have greatly exceeded the value of the service. Due to changes in technology, ebay was able to reduce the cost of an individual transaction to essentially nothing, creating opportunity where once there was none.