When a developer inherits a codebase, there is always a case of NIH(not invented here) syndrome. I am guilty of it, but with experience and professional maturity I have become more objective in my evaluation of third-party codebases. Recently, I had the chance to work on a codebase that ticked all the boxes of what a good software application should contain. The codebase exhibited the following characteristics:
- Unit testing and Mock objects
- Dependency Injection
- IoC Containers
- MVC
- N-tier architecture(and a slight hint of domain driven design)
- Fluent Interfaces
- NANT builds
- Code-generation
- Template meta-programming(generics)
These are fairly advanced concepts in software engineering and represent the software engineering zeitgeist. Unfortunately these practices will be lost on the majority of enterprise developers(unless you are working in a dedicated software shop that’s at the bleeding edge). For the typical enterprise developer, this translates into is software that is harder to maintain, extend and for which the sprint velocity is going to be dismal. The inheritors of the codebase have the additional task of understanding the domain and the engineering approach.
The question then becomes: how do you balance the need to create supple software systems whilst staying true to the software engineering discipline. Can you sacrifice the need for rigour in favour of comprehension and program understanding or vice-versa?
No comments:
Post a Comment