Software Values

The ship of Theseus is a thought experiment that comes to us from Plutarch, a Greek philosopher who lived during the 1^st and 2^nd centuries.  Recorded in the “Life of Theseus”,

"The ship wherein Theseus and the youth of Athens returned from Crete had thirty oars, and was preserved by the Athenians down even to the time of Demetrius Phalereus, for they took away the old planks as they decayed, putting in new and stronger timber in their place, in so much that this ship became a standing example among the philosophers, for the logical question of things that grow; one side holding that the ship remained the same, and the other contending that it was not the same."

Here is a video version for visual learners,

So what does the ship of Theseus have to do with software values?  Good question, before we can answer it we will need to answer the question, “What gives software its value?

As a software developer it is your job to provide a valuable solution to your customer’s problem.  The customer can be internal to your company or external to your company, in fact you can even be your own customer.  The value that you add to the solution can be time saved, energy saved, money saved, or money earned.  In general, it is because of this value add that your customer pays you to deliver a solution.  This becomes blatantly obvious when you deliver a solution that does not work well.

What Gives Software Value?

What makes the software you write valuable?  I’m guessing your answer is on some level a reflection of the ideas covered above, “I write software to solve problems for customers.”  But solving your customer’s immediate problems is only half of what makes your software valuable. 

In his Clean Code series, Robert Martin discusses how software has two kinds of value.  The primary value of software is that it is soft; think maintainable, scalable, and readable.  The secondary value of software is that it solves your customer’s current problem, this means that the code you deliver does what the current customer currently needs without issue.

Back to Theseus

The primary value of software is that it is flexible and able to grow to meet the changing requirements of the customer.  Think of the ship of Theseus for a moment.  The ship of Theseus’s secondary value was high because it functioned as a ship as defined by the customer upon delivery.  However, a ship made out of a singular piece of wood would have also had a high secondary value.  The ship of Theseus’s primary value was also high because the design of the ship accommodated the customer’s needs changing from sailing to the preservation of the ship.  A ship made out of a singular piece of wood would have a low primary value due to its inability to accommodate change.

The ship of Theseus was designed in a way that allowed components (planks) to be replaced as necessary, instead of requiring that the entire structure be patched with each change.  Like the ship of Theseus we should design our software to have both high primary value and high secondary value so that it can remain resilient in the fluidity of our customers changing needs.

It’s Our Job

As designers of software it is our job to keep both the primary and secondary value of the software we create in mind as we create it.  Delivering software with a high secondary value and a low primary value is easy and will make the customer happy short term.  Delivering software with a high secondary value and a high primary value is difficult but will make the customer happy long term.

Is Software's Primary Value Always Important?

Yes!  Putting thought into how to make your software readable, scalable, and maintainable is never a bad idea.  Your software will never be too readable, it will never be too cohesive, it will never be too loosely coupled.

Can We Spend Too Much Time Maximizing Software's Primary Value?

Yes!  It is not possible to anticipate every change your customer will request throughout the lifetime of your application, so don't try.  Understanding that software has both a primary and secondary value is a good start.  In fact, I guarantee that if your sole focus is on maximizing your software's primary value you will effectually minimize your software's secondary value, and never actually deliver anything.  Luckily we don’t have to write code that accounts for every possible change our customer could ever request in order to achieve high primary value.  Over the next couple of blog entries I will discuss the SOLID principles of software design, which will serve as a guide for writing code that delivers both high primary and secondary value.