Laws of Software Development

In speaking with people about the complexity of software development, one comparison I’ve often used to describe it is to relate software development to physical engineering. Engineering can rely on physical constants that can be expressed as formulas or constant numbers. For example, the tensile strength of AISI 1018 mild/low carbon steel is 53,700 psi. Standard gravity is defined as 9.80665 m/s2. Engineers can rely on numbers such as these to design and build objects.

In software development, complexity arises because there are very few (arguably zero) constants that we can rely on. At any given point, something can fail or not preform to specification. Life would be far easier for software developers if we could rely on a network connection always operating at a certain speed, or a CPU operating at a certain capacity, or a database never failing, or a file system never becoming full…the list goes on of the failures that could occur.  But we cannot rely on these failures not occurring and we must build in the ability to handle these failures, and this drives up complexity. Not having a defined set of laws to operate by makes it all the more challenging.

Interestingly, we find that the reverse is often true with the softer side of software development. Over the last few decades, numerous rules, laws, and heuristics have emerged from software project management that describe the nature of software development. I thought it would be fun to highlight a few of them – let me know your experiences in the comments!

Eagleson’s Law

Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.

Brook’s law

Adding people to a late software project makes it later.

Galorath’s 7th law

Projects that get behind, stay behind.

Conway’s Law

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

Hofstadter’s Law

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Advertisements

The Software Project Model is Broken

*cross-posting from LinkedIn*

Yes, I went with a provocative headline to grab your attention.  It must have worked because you are reading this.  So don’t stop now – let me put some ideas forth to stimulate discussion and thinking.

First of all, I’m not the only person who thinks that this headline has some merit.  My friend Chris Sheridan posted on this topic last year.  Other very smart people have also published pieces declaring the project model dead.  There is a“#NoProjects” hashtag on Twitter.  (Because you need a hashtag for a movement like this)  So I’m definitely not alone and completely off the ranch with this thought.

There are two fundamental issues that we are seeing with the concept of “software projects”, especially as they exist in today’s world of agile software development.  Perhaps the concept of a “project” fits far better with a waterfall approach, but as our industry transitions to agile development, the concept of a project starts to confuse the situation.

First and foremost, software – and especially custom software – is often not thought of as a long-term investment in a capability or service.  It’s most often viewed as a large one-time expense to the business, because it’s typically fairly expensive to pay for during initial development of the product.  (Note: I’m ignoring the financial perspective of this via a cap-ex model.)

Secondly, projects (of any type) by their very nature are defined to have a beginning and an end, and are temporary.  Even the Project Management Institute defines projects this way.  So why are these two concepts causing issues?  Let’s explore…

Why do we use software in business?  There are several subtly different reasons, but at the end of the day, it is either to enhance productivity and drive down costs, or to provide a service or capability to customers to generate revenue.  And to be competitive today, companies need to provide a continuous flow of new value to customers.

We already know that software is not a one-time investment…it’s like a pet.  Yes, you pick it up from the shelter, get a leash, get some food, pay for a vaccination, buy a bed and some toys, and quickly you are out $500…and then you buy food every week for the next 12 years…pay thousands in vet bills…buy hundreds of dollars of toys…pay hundreds in boarding fees over the lifetime of the pet.  So while you think you have a high initial investment, you actually end up paying far more over the lifetime of the pet than you did when you got home with them.  It’s very much the same with software.  While the initial investment to get that first product out the door seems high, it is going to be less than the ongoing investment.  Yet we focus on the cost of “the project” – that initial investment, and we often ignore the larger lifetime cost.  Companies also tend to ignore the competitive nature that innovative software solutions bring.  As I wrote earlier, to be competitive, companies need to continually invest in their solution to bring new features and capabilities to the market.  Projects with end dates don’t work well with the need to continuously provide value to customers.

This slides into the second issue: the end of a software product comes when the true end of its lifespan has arrived.  The end of a piece of software is not when the “project” is over – it is when that software is fully retired from service.  When it’s uninstalled from servers, removed from desktops and devices, and deleted from app catalogs.  Until then, it’s costing you money to run and maintain.  The end of a software “project” is when you want to stop investing in it – not when you reach some arbitrary or estimated date.

So what are companies doing to re-think “projects”?  Companies doing innovative work in a continuous flow model have re-thought the concept of “projects” to an “investment streams” model.  We are seeing great success with organizations who have re-aligned their delivery teams by portfolio/product areas, which map to business investment streams. If there is a new capability or product your company wishes to invest in, it is smart to think about the level of investment that you are going to put into the capability over the life of it, from the first day to the last. After all, if it’s a great product, your users are going to be demanding additional capabilities – so don’t be stuck in a project mindset!