Programming has approached a level of professionalism that suggests we now spend a lot of time meta-programming, naval-gazing and writing a whole lot of complex code just to avoid smells.
Meta-programming could be described as programming about programming. As our tools get more advanced and our systems get faster, we can now write code that writes code and write code that analyses code. What’s the point? Visual Studio has finally integrated the Roselyn Compiler-as-a-Service feature which brings the compiler in as a first-class citizen so you can generate code and analyse it from within your own program. But wait, the last time I looked, it was an anti-pattern to dynamically generate code.
In order to leverage new features, avoid the judgement of our peers or even ourselves, we’ll go to great lengths to create patterns of best practice which decouples concerns, increases testability and complies with the latest guidance of our peers – however much work that may take. We must avoid the Anti-pattern, lest we be judged.
But the Anti-pattern is still a pattern, so suggests some level of thought and maturity.
I’m reminded of the Capability Maturity Model (CMM), which is a model of maturity applied to organisations to identify whether their processes are chaotic or structured so are repeatable, measurable, testable and therefore able to be improved. Of course, the software industry hasn’t allowed itself to avoid its own naval gazing and has come up with various mirror models. Many of these are arbitrary and perhaps form an extra string to a consultant’s bone, such as the Software Development Maturity Model, the Software Assurance Model, and of course there would be an Agile Maturity Model developed by … a consultant.
We’re perhaps too quick to judge software code and not understand why it is what it is.
As a developer, one of my struts for my professionalism is the decoupling of concerns. This is simplified such that no module ultimately depends (or even knows) about any other module. You sort of “wire it up” during a bootstrapping process. At the moment. We used to think that modules should know about each other, but perhaps on a more restricted scale, so the database would be “known” by the behaviour, but not the presentation. Now, technology has come so far and developers’ minds have grown so large that we now realise this is bad practice. So we use Dependency Injection whereby a single element of the code performs the wiring up, invisibly, automatically and somewhat magically. You don’t need to know how, just why. Wait … what?
Dependency Injection develops on the previous best practice, the Service Locator – which is now an anti-pattern. But I know how and why with that pattern. But it was a pattern. A Service Locator could be regarded as a central authority for identifying what modules in your code did what. You’d go to this and ask for the code to access the database or perform a particular process. It was, in effect, a global variable which itself had developed from previous practices.
Last night, about 2am, I found myself writing a service locator Anti-pattern, direct from Microsoft’s evangelists, no less. This is the NavigationService (the clue’s in the name, I realise) which was passed around as a property in view models within Windows 10 apps using the Template10 project. I immediately recoiled. Sure, they’re passing it around as a property, but it is still a Service Locator. But it is also 2am. A pattern’s a pattern. And I went with it.
The fact that there is a scale of these practices, each time evolving to improve their perceived professionalism based on a fad or a consultant’s USP, suggests maturity. Using the Service Locator, I deliberately considered the risk (code smell, limited decoupling, global variable in all but name) with the benefits (it’s 2am) and strategically decided on an outcome. According to the ubiquitous CMM this at least puts me at level 3 – it’s a defined process that is documented and can thus be improved.
Best practices avoid code smells and become themselves anti-patterns. You just need to look to spot this moment and switch tactic at the right time.
The maturity here is the consideration of the time, the rapid delivery that is so craved by Agile techniques and the enthusiasm to get to the next problem and using an anti-pattern – but knowing why and committing myself to returning and improving my own process later. I come across anti-patterns regularly, after all, no developer ever said “wow, the previous developer’s code is certainly better than my own.” But I stop and think. Considering how busy I am now, could this not be where my predecessor found himself? Was that the best practice at the time?
So my Service Locator Anti-pattern is justified. Publicly. Deal with it.