For those that have been in the software development, tech, or IT field long enough will probably have noticed it has (d)evolved into a series of tech-checklists that have captured the industry flag. For instance, you must have this framework, and that pattern or methodology, and that list has formed derivatives (or mash-up’s), which has become monolithic and compulsory.
It used to be that if you were a strong software developer, the “expectation” was that if you are proficient in these programming languages that you would come up to speed on this methodology, and that pattern and framework because THAT is what developers do. THAT generally doesn’t appear to be the case anymore. Some might think that could be due to outsourcing, or more engagement from HR departments and recruiters, but I think it’s much more than that.
I liken this new phenomenon to less faith in critical thinking, and more emphasis into a task-based, shaped mindset. You can see this shift in many other aspects of society too.
Patterns for the Sake of Patterns, Frameworks for the Sake of Frameworks
Over the years I have adopted more of a keep it simple approach, and so I tend to have one eye out for all things overly complex. For instance, development cycle methodologies have just gone off the deep end in my opinion — by the time your team has got accustomed to this methodology, it has changed significantly, such as with SCRUM, Kanban, and mashup’s of the same. I recently examined the MVC 2.0 patterns for building a mobile application I am working on in Xamarin/C# and have found separation of a layer already separated. It’s not just in the C# community, the same over separation mindset exists in the Java world too, such as with DAO patterns. So goes with their related frameworks; they get forked, and that something new takes off and soon the masses converge on it until the next fork. Lather, rinse, repeat.
The Cost of Momentum Driven Methodology
Developers see this too, and must look for every opportunity to try new things in the name of anything that will stick, but it’s mostly rooted in self-preservation or self promotion. I have read countless posts from accomplished and respected developers who discuss having used this pattern alongside that framework (which is a clone of other frameworks). They talk about doing that “next thing” on the “next project”. Frankly, when I see numerous frameworks popup to support a new pattern, I tend to scrutinize the pattern itself. Like chickens with our heads cut off, we consume these things because momentum dictates, and not so much on the real merits (and by merit, I mean scrutinized). And, so goes the social justice revolution, but I digress.
This isn’t a good thing for technology leaders because it increases their complexity, which carries significant cost (whether they see it or not). Not just in monetary terms, but in morale, time to market, customer achievement, etc.
We are all just cogs in a wheel and so it can be difficult to break out of it, but we can raise visibility to this phenomenon. Technology leaders can do something about it, too. By focusing on “the need” and not “the tech” we posture ourselves for more clarity of thought, and from that clarity I believe we will see more value in keeping things simple, and remaining lean.
The More Things Change …
[Queue up an old Rush tune (Circumstances) from an older French expression] The older I get, the more cycles I realize that I have been exposed to, so this cycle will probably be no different. Things tend to go in swings and each swing is a result of “over compensation” from the opposite direction. So, while things in IT and software development used to be aimless or the wild wild west, this over compensation to complex-ify, name and fork everything should eventually die down.
Until then, I hope we can all take a step back, breath, and remember that all these things are meant to serve us, and not the other way around. When we get caught in tech rituals, we lose sight of the spirit behind the religion of tech.