Software Evolution

June 1, 2003 by
Filed under: Project management 

We can learn a lot about software development by observing how people manage their e-mail inboxes. For years, even though I would diligently move important information into specific folders for later retrieval, control of my inbox had escaped me. Despite all my best efforts, it was almost impossible to cull it down below a threshold of hundreds of messages. The effort required to regain control was beyond me. I’ve seen others that don’t manage their mail at all, and the number of messages in their inboxes number into the thousands – retrieval of any relevant information is a daunting task.

I had the wonderful opportunity to start afresh a year ago, and the current total number of messages in my Inbox and Sent Items folder is 3 (I’m sure there are those that could find derisive anatomically-derived terms for me at this point…). The difference: I decided up front that I would remain diligent in staying on top and in control of the situation. These days if my inbox gets to be over 10 or 15 items I start to get a bit antsy, and the weight of this new management approach is not a burden – I am flossing my inbox regularly. I strive to deal with a piece of mail only once, then either file it, forward it, or delete it.

So what’s this got to do with software development? Meir Lehman, who started investigating software evolution over 30 years ago and predicted the demise of IBM’s OS/360 operating system, has evolved his thinking into a set of laws governing the evolution of software programs.

These laws are more generally applicable today than when they were originally devised. In a nutshell, Lehman suggests that for a program to remain useful in the real world, it must evolve over time. With that change, its structure becomes more complex, and must be appropriately managed. As the application evolves, system attributes such as time between releases and number of reported errors don’t change significantly for each release. Its rate of development and the incremental change in each release is approximately constant as well.

Here’s my distillation of Lehman’s Laws: if what you are working with (a software program, an e-mail inbox) is intended to endure for some time, expect it to increase in complexity as it evolves. Start up front with an approach for managing that complexity, and don’t expect to be able to easily manage increasing complexity after the fact. This perspective will drive you towards more focus on oversight, scope management, and architectural design, elements that are rarely apparent in software applications (or inboxes) that have gone awry. The bottom line is that the lifespan of your application goes a long way towards determining the appropriate level of planning and diligence to apply.

Lehman’s Laws were part of the foundation for the more famous Brooks’ Law (the Mythical Man-Month), and for the most part can be generalized to govern any long-lived and growing managed organism – like an e-mail inbox. Unlike Lehman’s views, I see this as another example that we in software development are bound by the laws of nature.

Recognizing these laws and their implications will allow us to understand the need for fundamental structure in how we approach development of real-world applications. This structure needs to be in place from day one if you wish to avoid a huge increase in pain over time. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September, 2017 – A workshop series to help you develop resilience in the workplace and in your life!

    Next open enrolment sessions start soon – contact us to get involved!

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • September 19-21, 2017 – Winnipeg, MB
    • October 4-5, 2017 – Regina, SK
    • October 21-22, 2017 – Winnipeg, MB
    • November 1-2, 2017 – Saskatoon, SK
    • November 27-28, 2017 – Edmonton, AB
    • February 10-11, 2018 – Edmonton, AB
  • What People are Saying

    I was pleasantly surprised that you could derive this insightful feedback from a relatively short survey.

    — Randy Tkatch, VP Engineering, Spectrum Signal Processing