Software developers generally occupy positions of considerable (if unacknowledged) power and trust within their organizations. The practice of software development necessarily involves dealing with minutiae in large quantities; in making making dozens of mostly small (but consequential) decisions each day. In aggregate, the effect of these decisions can be (and often is) of enormous import to the business or organization that employs the developer.
The number of decisions that a software developer must make, in general, precludes effective scrutiny by the traditional authority structures of the organization (the bandwidth required to communicate the context and consequences of each decisions would increase the time taken to make the decision by two or three (base 10) orders of magnitude). As a result, organizations are forced to place a large amount of trust in individual developers, effectively granting them carte-blanche for their actions.
As a result, software developers are often in positions that confer considerable power and authority, with little of the visibility or accountability (or remuneration) that normally comes with such positions.
Furthermore, the interaction between developers and the traditional management hierarchy is typically pretty dysfunctional. Most organizations management structures are staffed with individuals who tend to emphasise and practice "soft skills" centred around sales, communication and persuasion, rather than attention to detail, patience and persistence. As a result, rather a lot of what developers do all day tends to slip under the radar.
Is it any wonder that the politics of the software development community tends to be oriented towards decentralisation, individualism, and (borderline) anarchism? This is the world that most software developers inhabit in their workplaces already. The superiority of decentralised decision making over centralised decision making is manifest to all of us - we see the evidence every day.
I was attempting to say that typical management stereotypes create an image of a person who either deals primarily in perceptions and impressions and only secondarily in facts and truths; or of a person who is so concerned with either being busy, or appearing to be busy, that only superficial communication and (mis)understanding is possible.
This is not necessarily an assertion about the extent to which particular individuals act out these stereotypes, or even a criticism of those who do: the situations that people are put in are often very difficult, and it is not obvious how one might ease the systematic dysfunctions of our institutions and organisations.
Furthermore, to say that the systems that we inhabit are imperfect and dysfunctional is to state the obvious: utterly uninformative without some sort of exploration or discussion of the whys, hows and wherefores. Fortunately, we have several models that we can apply to the analysis:
Any attempt to route significant information flows through a lossy and bandwidth constrained channel such as the human brain is bound to suffer distortion and loss. The dysfunction is with the system; indeed, any system that attempts to move the power to make decisions any sort of distance away from the sources of information which that very decision making process requires, without making adequate alternative arrangements. Indeed, if you look at Hayek's take on the free market economy, the main magic is in how prices signal the imbalance between supply and demand, and, indeed, we see analogous attempts to summarise key information through statistics where stereotypical and long-lasting information flows exist. However, it is less obvious how to summarise and/or compress idiosyncratic and short-lived information in rapidly changing and evolving circumstances.
How to fix this? Software and Information Technology is supposed to be a major part of the solution, but I have seen little that promises the paradigm shift that (more than likely) will be required to achieve the orders-of-magnitude improvements that we seek.
That was a great post, thanks. I'd like to add another point - one may need paranoia [the common, not medical, interpretation] to make all that power work without bugs.
You know the quote about a good programmer needing laziness, impatience, and hubris? I disagree, for many systems it should be laziness, impatience, and _paranoia_. Paranoia puts in asserts and assumes any untrusted input is just that, and puts in documentation for the future 'you' on the project to consult. Because as you say, nobody has your back or will review your trickiest code (on the average funded project with one smart guy doing most of the work), and frankly, hackers _are_ out to get your code.
So when we don't have an explicit check against something, the behavior is undefined. And when there is no check against power , we know where the road leads.
Well, one of the nice things (I think) about being a software developer (and one-time "scientist") is that you get to measure your mettle with nature - to test your ideas out in the real world - to see if your preconceptions hold, or if your ideas are only so much hot air ... and all too often, they are. My initial ideas are always wrong (well, most of the time), and I pretty much always need several rounds of testing against reality to refine my designs into something workable.
Getting the right answer is hard. Really hard. I never understood how some people could go through life and avoid ever being wrong; dancing around responsibilities, never taking the blame, being driven by a (frankly irresponsible) culture that demands perfection.
For me, my failures are lessons; mistakes marking a path of learning and progress.
Good will; systematic persistence; humility and humour - all recipes for learning and improvement: Flashy self-aggrandisement, an emphasis on performance and (self-proclaimed) brilliance: all recipes for deceit, lies and failure.
The number of decisions that a software developer must make, in general, precludes effective scrutiny by the traditional authority structures of the organization (the bandwidth required to communicate the context and consequences of each decisions would increase the time taken to make the decision by two or three (base 10) orders of magnitude). As a result, organizations are forced to place a large amount of trust in individual developers, effectively granting them carte-blanche for their actions.
As a result, software developers are often in positions that confer considerable power and authority, with little of the visibility or accountability (or remuneration) that normally comes with such positions.
Furthermore, the interaction between developers and the traditional management hierarchy is typically pretty dysfunctional. Most organizations management structures are staffed with individuals who tend to emphasise and practice "soft skills" centred around sales, communication and persuasion, rather than attention to detail, patience and persistence. As a result, rather a lot of what developers do all day tends to slip under the radar.
Is it any wonder that the politics of the software development community tends to be oriented towards decentralisation, individualism, and (borderline) anarchism? This is the world that most software developers inhabit in their workplaces already. The superiority of decentralised decision making over centralised decision making is manifest to all of us - we see the evidence every day.