Software Feature Entropy Cycles

I'm overdue for a long-winded article. I used to post a lot more of these kinds of brain dribble, but I took a break from it for reasons unknown.  You've been fortunate.  Tonight, I just finished playing whiffle ball, eating spaghetti, and laying on the couch watching The Sandlot on TV.  My brain juices are flowing, so you know what that means...

There's a lot of talk about the "life-cycle" of software, and "life-cycle management", yada yada yada. But there's another "cycle" within software technology that doesn't get talked about much. This "cycle" actually has more impact on professional lives, and the course of technology than most of the other "cycles".  If I were to borrow a bit from Kevin Kelly's "What Technology Wants" (a great book, by the way), I'd probably coin the term I'm talking about as "Feature Entropy".

Before you start thinking I've lost my mind, or that I'm blowing smoke, hold on and hear me out.  This will actually make sense.

Programmers everywhere make their living filling in gaps. Feature gaps.  The gaps that exist between what a retail software product (or service, or technology) offers, and what you or your customers/users really need. Whether it's custom templates for content creation, or formulas for spreadsheets, or reports from databases, or components to connect services, or applications to solve problems.  Whatever.  So, you install Windows, or OSX or Ubuntu or Android, or iOS, whatever, and you discover you need something to solve a problem.  Maybe it's just automating a common task; maybe it's for pure entertainment.  Maybe it's to earn additional income.

This is when you start brainstorming and designing a solution.  From that design, you start tinkering, and building key pieces of this puzzle.  Soon you have portions linked together and things start to take shape. You get excited, and realize it's almost 3:00 AM and you're still driven to write more code, but you're about to crash.  You wake up, stretch, hit the bathroom, eat and start coding again.

Sound familiar?

This is actually the first phase, or "phase one" of the entropy cycle.  Phase Two is when your solution is running on it's own legs and enters production.  Phase Three is about maturity and refinement.  Phase Four is about absorption.  By that, I mean when the vendor realizes that a lot of developers are building the same general type of solution for a large install base.  The vendor realizes that there is value to be gained in absorbing that solution into the next version of their product.  The next version comes out and, if customers find value in the improvements (versus the perceived challenges of new changes), they buy the upgrade and now that class of "solutions" you and many other developers were thriving on is no longer required.  That would be Phase Five, or "closure', in some respects.

That may sound like doom and gloom, but the machine rolls on.  Developers size up the new version and find yet more gaps that need filling and they continue on.  Nothing is truly a "one-size-fits-all" solution for all customers.  That is what makes it possible for developers to exist.  It's why builders build custom houses, and why auto-detailers customize cars.  People want, even need, for things to be a certain way in order to fulfill their needs.

The entropy here is the logical flow of features from outside to inside.  Outside being the developer community at-large.  Inside being the vendor who makes the base product or technology upon which the developers are building their tools that fill the gaps.  As features are incorporated into base, and versions roll onward, the flow continues inward.

If you really want to get technical about this "flow" aspect, it would be more accurate to describe it as toroidal.  That's right, a Toroid. This is because there is also and outward flow aspect to this cycle.  Vendors invest quite a bit into extensibility, not because it makes customers feel good, or to be altruistic.  They do it because is helps to grow an ecosystem that spreads the use of their products, while also building a community from which to cultivate ideas and features to be absorbed into future versions and future products/services.  It's kind of like scattering seeds in a field and watching the flowers grow, especially if the person spreading the seeds is a florist.

Entropy is really not the best word, because it implies decay or destruction, but in some references it can imply a sense of equilibrium.  It's that aspect that made me think of it.  Inflow or Convergence might be better words in some respect, I don't know.  Basically, there's an outward flow of technology, extensibility, and support which germinate as a community and grow into a revenue stream and ecosystem.

There's an inward flow of ideas, concepts and features, which help to grow the core of the revenue stream: products and services.  As ideas, concepts and features are plucked from the outside and incorporated into the inside, new ideas, concepts and features rise to the top, and the cycle continues.

The circle of (software) life.  Please don't start singing that movie soundtrack, mmmkay?

I promise future posts will be more coherent and entertaining.