The basic machinations of the jobs shift can also be explained by the commoditization of programming. In fact, if you were a dBase user, you’ve already seen this, as dBase was part of an earlier wave of commoditization of CICS/COBOL jobs and RPG jobs on the mainframe.
So, it’s important to wonder if you’re seeing something that can be repaired with a movement, or if it’s a permanent structural change in the market and industry.
It’s also not really a successful strategy, but we still suffer from a fundamental lack of software development management understanding in the biz, and stakeholders still don’t know why they should hire more capable people, how to structure a management system to leverage them, and worse yet, how to differentiate competency from mere, minimal capability.
Microservices? Maybe. The vast majority of devs claiming competency in microservices don’t know the first thing about service architectures, and are merely creating the same old distributed monolith problems that Distributed Objects did a generation ago.
There has yet to be a first birth of software production management competency at large. It’s not a re-birth that we need. It’s a birth. Period.
Until then, stakeholders are going to go for the less expensive commodity stuff, because disappointment or outright failure remains such a common outcome.
As for the .NET world, it’s always going to be a commodity developer market for bureaucratic, corporate environments that almost never pursue greater competency. That’s because of organizational structure, organizational mechanics, and compensation structure in corporate bureaucracies:
The person two levels above the average software project is typically not compensated any better for a software team pursuing greater outcomes, and their existing compensation is comfortable enough to not require them to reach for something new and innovative until the moment that continuing to do so becomes a personal risk. But they will be compensated less if they try something new and it doesn’t deliver. And given the typical level of low engagement in software development technique of software staff in these organizations, new and innovative things aren’t likely.
We succeeded in changing .NET and Microsoft with ALT .NET because it was a perfect storm. The goal wasn’t to create ALT .NET. The goal was to be fucking awesome software people who networked with other fucking awesome software people so that we could become even more fucking awesome software people. And when that kind of unvarnished thrust toward excellence happens, others start to sit up and take notice.
ALT .NET is it’s own establishment now. It has made some minor variations on the theme, but it’s largely the same pursuit of the same old patterns. Does anyone ask whether we can move on from IoC containers? Are there patterns that we haven’t realized that obviate the use of mock objects? Is there anything wrong with BDD?
Adherence to ALT .NET is the abiding goal of ALT .NET; to be seen as being associated with ALT .NET. That means that ALT .NET will remain in a fixed position with a fixed body of knowledge. The goal is to “be” ALT .NET, or at least “be seen” to be ALT .NET. And that means that whatever ALT .NET is, it cannot change. In effect, it suffers tremendous, harmful afferent coupling and can no longer move forward.
To have a renaissance, the .NET community will need to let go of the expectation of being visible and admired by the greater .NET community. The progenitors of ALT .NET weren’t after ALT .NET. They were after fucking awesome software work that wasn’t a soul-grinding trudge through hell.
You can’t cause a renaissance. You can only recognize that somehow one has started to happen. If it happens it will be because of people who are focused on excellence. And it will only happen if those people absolutely do not care about being popular or populist.
ALT .NET was a splinter group. We were disenfranchised, so we created our own community off to the side. That is a very difficult bit of work that takes many, many years. If you end up with a renaissance five years from now, it will because you started something now that couldn’t give a damn about whether a renaissance comes of it.
Get focused again on the critical thinking and critique of the current state of the work, imagine better alternatives, and pursue them.
ALT .NET was not an overnight success, and its goal wasn’t a movement. It’s goal was to change the nature of our work in .NET without giving a damn about what the mainstream said, consequences be damned.
If you focus on excellence and critique, it might happen again.