software creativity vs. escaping poverty = similar psychologies ?
I read this article today, and saw similarities between the psychology described with that of the creative aspects in software development.
Specifically, that in relation to common practices at a wide range of companies that enforce specific technologies and structure architectural review around the “how” instead of the “what, and why it’s important”, these practices produce the same net result in a software engineering team as described by the article. Software engineering teams have become the impoverished who are unable to escape these kinds of environments.
Read this direct quote, and then think for a moment about the software team you’re on and its organization at large.
“Fewer options do reduce freedom. But now, we may need to grapple with a new possibility: that poverty doesn’t simply reduce freedom by constraining an individual’s choices, but that it may actually alter the nature of freedom by reducing an individual’s willpower.”
If you have any sort of general technology constraints, architectural review committees and the like, what is the focus of their charter ? Where do they focus their attention when holding panels ?
Reduced willpower to think for myself due to misguided technology and political constraints ? Check. No surprise here, treating people like 5 year olds who are incapable of thinking or making rational decisions of their own will result in people who no longer try to think or make rational decisions. They’ll defer to TheAuthority.
We’re killing the most important and differentiating aspect of the software engineering profession as a whole, its creativity.
There’s a time and place where such structure is significant and valuable, but not across the board, and not solely for the sake of “maintaining better engineering practices”. There are plenty of ways to accomplish the latter without resorting to such methods, if only the advocates of these methods would open their minds and learn to accept the possibility of that fact. The practices themselves aren’t even the problem, but rather, their application and the mindset of the people doing so.
It doesn’t matter if you’re a massive global company or a tiny startup, spending time in these ways should be about improving your software in a way that ensures changes occur and problems are identified when it’s cheapest to fix them, as early as possible in the project’s life cycle.
Focus more on what is being done and why, less on how at the lowest levels, you’ll be surprised at the difference it’ll make.