This is the second of my posts on the topics of Lehman’s Laws of Software Evolution and how they relate to agility. I’ll probably only post one per week over the coming months. If you have not done so already, you should go and take a look at my introductory post over here.
Law 1: Continuiung Change
An E-type system must be continually adapted or it becomes progressively less satisfactory
The need to adapt to change is at the heart of all agile development. The need to adapt to change is the reason agility in software engineering exists. With Law 1, Lehman basically predicted this all the way back 1974.
I think, to anyone who has worked in software development, this is a fairly obvious statement. Change happens and our software needs to change, too. Users change, hardware changes, the world changes and the software we write needs to keep pace with that.
The environment forces changes in requirements and the software needs
to adapt in order to stay relevant. Simple, right? Well, that all
depends on how we define
Adaption In Agility
Ever worked for a team where agility means “get me more features as fast as you can?” Sadly you were (or are) trapped inside a feature factory. This is not really agility and I’ve very rarely met engineers who enjoy this mode of working.
Adaption can really mean quite a few things. Sure, adding new features. But also:
- Removing features
- Changing existing features
- Altering the delivery mechanism
There are 1,000,001 things we do to our software as engineers that has nothing to do with adding new features. And we know all too well, these things must get done.
If your agile process is driven by features, that is absolutely fine. Feature-driven Development is a thing after all. What is crucial, however, is the cultural maintenance the team must do when following a model like this.
Driving your project with features is fine, so long as we remember the rest of our house-keeping, too. Engineers are doing waaaay more than simply shipping features and it is hugely important to recognise all of the hard work in the team and not just the shiny new stuff.
Notice that I managed to get this far without talking about QA as one of the major, non-feature-driven actvities of software engineering? Guess what the next post in this series will be about.