The first post in a series regarding Lehman's Laws and how they impact your engineering.
Some of my favourite "things" in the theory of engineering management are Lehman's Laws of Software Evolution. These laws are almost always sitting at the back of my mind as I work; they have implications for the product, the team and the process.
I am going talk a little about how I see these laws relating to agility and why you should maybe also think on them. But that's going to take a few posts. For now, I want to start with the nature of software evolution itself.
Kindly, someone over at Wikipedia has defined "software evolution" in a way that I like...
Software evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing software initially, then repeatedly updating it for various reasons.
I like this definition because it starts from the begining. With the empty file. All software development starts with the evolution (and maintenance) of an empty file. The final software product, however, does not necesarilly evolve.
Lehman broadly categorises software into one of three types:
Broadly, I guess we reduce this to "some software evolves, some doesn't". In general, I think it is pretty easy to identify which is which. What is not so obvious: how does the type of the software affect the environment in which it is being developed?
I'm going to tackle Lehman's Laws one-at-a-time in blog posts. For each I will try to provide insight from my own experience and relate the law to agile practice.
But, for now, head on over to Wikipedia and read around Lehman's Laws and get a feel for how they relate to your experience.