Everybody knows that being agile is THE way to go when building a software, and almost everybody nowadays wears the agile badge, hoping that it will solve all the world’s problems (aka missing deadlines, software not meeting requirements and so on). But since agility is just a characteristic, it is equally applicable to both developers and the software they develop.
An agile developer is one who is open to change and understands that change in software and its requirements are imminent. To counter these changes, an agile developer uses certain concepts, such as –
- Regular Interaction and Feedback from all the stakeholders.
- Less Documentation and more focus on deliverables.
- Short deadlines and milestones.
- Test-driven Development.
- Continuous Integration.
- and so on…
And of course, we have certain methodologies and frameworks that are implementations of these concepts, like Scrum, XP, and others.
With all this focus on being an agile developer, one thing that quickly gets out of focus is the Agility in the software. We can consider an Agile software as a software that is Easy to change with changing requirements. And although the idea looks similar to concept of an agile developer, it is very different because even if you are an agile developer developing in a very agile way, that agility is not very useful if you have a codebase that is very hard to change, is too complex for even a smaller requirement change or is too rigid.
Another important aspect is that as a software grows, it becomes much more complex and has more and more code (modules that interact more with each other and often have more coupling with more requirements). This has a negative impact on the agility of both the software and its developers because adding and modifying features takes more time and gets more difficult. Rich Hickey rightly calls these complex rigid systems as The Elephant in the room.
Developing Agile software makes developers Agile, Not the other way round!
As developers, our focus should be on writing software that is easy to change and maintain, and although all the process and techniques that agile brings with itself are good and useful, they are useless if the software delivered is not good. Essentially, there should be more focus on things like-
- Design of the software – Identifying right abstractions and components is key and should be stressed more throughout the system, Separation of software in physical and logical modules is the key in making software that can be changed easily and reliably.
- The simplicity of the Software – Simple things is easy to understand and therefore easy to modify. Creating a simple Utility can be preferred over a plugin that brings three other dependencies with itself. Using native data structures of a language is always better than using custom data structures (Maps can be used in place of classes), polymorphism can be used in place of code branches. It’s important to weigh the benefits of using any tool or library with its complexity and cost of maintenance
- TDD – TDD should be done to test behaviors and not just code. This verifies the software at the level of design and not implementation. Bugs in design are much more costly and much harder to fix than Bugs in implementation.
Always remember that the purpose of whole agile software development is to write better software, software that we can understand, change and make do more things as we need. And as such, we should have an eye on the agility of the software we are making as we try to be agile ourselves.