To a large extent, most of the software team managers I met in the course of my career were not able to judge neither the qualities nor the techniques required to create a software artifact. They were incapable of understanding the very work made by the teams I joined, the same work required to complete the software they clicked or touched at the end of each sprint. Yet most of those non-technical managers were by large the most inclined to take decisions that did have a major (usually negative) impact in said work, and not once, but rather very often.
Even worse, many were proud and even bragged about this fact.
On the other hand, the few tech-savvy managers I have had the fortune of working with took, paradoxically, few to almost no decisions at all; and when they did, they had such broad (positive) consequences, that they remain to this day engraved in my memory as examples to follow.
Anecdotes
This anecdotical experience is shared by nearly all software engineers I have met, regardless of nationality, culture, technology, or age. It is an important part of the folklore of writing code for a living. We all joke about this fact, day in, day out. We have all heard those stories. We tell those stories at conferences, we write books about them, we laugh at them at the bar.
Let us enumerate some of those classic stories.
A non-technical manager firing the politically-unaware yet gifted core of a software development team, while leaving in place those members who were not as versed in technical matters, yet excelled in political gambling, only to see the whole organization go bankrupt a few months later.
A company evaluating (and eventually firing) developers depending on the number of lines of code written, the number of tickets closed per unit of time, or any other metric easily visible in Jira, Redmine, GitLab, or similar tools.
A human resources department reminding developers, with passive-aggressive e-mails, that code must only be written within the office firewall from 9 AM to 5 PM, that home office is a privilege with draconian constraints, that an impossible dress code must be respected during the hottest of summers in said office without ventilation, among other inane requirements.
A developer blocked from writing any code during months, because they could not install the required developer tools in their company-provided laptops, because security and rights and approvals and bureaucracy.
A brilliant asshole, usually a white man in his early thirties, dismissing months of work upon arrival, treating everyone as utter garbage, harassing female employees, causing whole teams to quit en masse, yet receiving praise and bonuses by every manager, up to the CTO.
A team member suffering from mental health issues notifying via e-mail to their superior and HR department, both of whom never reply to said e-mail, and promptly dismiss the employment contract the following month without further due.
We could continue for pages, but that is not the point of this article. (For those asking, yes, these stories are all true, and sadly the author of these lines has witnessed them all.)
The Other Side
It is only fair to pay attention to both sides of the fence.
Most of the software developers I teamed with during my career were incapable of understanding the constraints and environments of the business paying them a salary. As a consequence, they were very eager to let the world know of their algorithmic considerations, put together in clumsily conclusions devoid of any actual applicability or substance, and more often that not, driven by the need to beef up their resumés. Sadly, this translated into expensive decisions, such as radical technology changes, complete rewrites, and many other catastrophes.
Even worse, many were proud and even bragged about this fact.
On the other hand, the few business-aware developers I have had the fortune of working with, had a growing interest in both commercial and software subjects, and were able to take technical decisions that actually benefited the bottom line of the organizations they worked for. They could enter in actual productive discussions with “the business” without the need for belittling anyone, engaging in respectful debate.
Cost Management
The problem, as it turns out, is a modern version of C. P. Snow’s observation in 1959 of The Two Cultures.
For the purpose of this discussion, this author will deliberately reduce the scope of management concerns to a single dimension: cost. In our capitalist world, sadly, the greatest (and often, the only) concern of “managers” is, without any doubt, the amount of money required to get a new “thing” online. Hence, here is the author hoping that the reader will endulge him in this diatribe.
Management holds dear to the phrase “you cannot manage what you cannot measure”. Yet experts in a well-regarded magazine such as IEEE Computer are still undecided on what to measure when it comes to software; and unsurprisingly, most root for counting single lines of code (the dreaded “SLOC”) as a basic measure for productivity and advancement. If they do not know what else to measure, who can?
Well, maybe Barry Boehm can. In case you have never heard of him, he is one of the first true researchers in the field of software engineering productivity and management.
In his 1981 paper titled “Software Engineering Economics” he went as far as to propose a formula to evaluate the cost of software projects. You heard right; this is an algorithmic method for software cost estimation (you can rub your eyes, I will wait for you); that is, a mathematical formula that could have been implemented in Excel 35 years ago. And, lo and behold, SLOCs are at the basis of the whole equation.
This rather revolutionary contraption was called the COCOMO, or COnstructive COst MOdel. An unfortunate name, distorted 5 years later by the Beach Boys as the soundtrack of a Hollywood blockbuster. But quite an incredible precedent, mostly forgotten by younger developers, and followed by the release of COCOMO 2.0 (by the same Barry Boehm) in 1995.
The major differences between both COCOMO models was the replacement of SLOCs as the only metric for software products, including “object points” and “unadjusted function points” as complements. The latter paper goes on to describe each one of these, and as you might infer, they were not immediately obvious to anyone outside of academia.
The first COCOMO, however, was algorithmically simple as to be included in a web service that some older readers of this magazine might remember: Ohloh. Available from around 2005 to 2009, it provided an early form of “social network” around open source code. In the page of each project tracked by Ohloh there was a cost estimation based on the COCOMO model. This way you could learn that the Apache web server project cost millions of dollars, and took years of man work to be finished.
Simple, maybe not entirely effective or exact, but sadly completely forgotten.
A decade later, Steve McConnell tried to shine some light into the subject of cost estimation, mostly through his book “Software Estimation: Demystifying the Black Art”. The biggest takeaway of this volume is the statement of the distinction between estimates, targets, and commitments. Just because of this first chapter (freely available online), this book should become mandatory reading for both Computer Science graduates and MBA folks alike.
Maturity, Or Lack Thereof
Anthony Finkelstein from Imperial College wrote in 1992 about the “Software Immaturity Model”. His paper bears a pun in its name, targeting the pompous Capability Maturity Model Integration process, also known as CMMI, proposed in 1989 in a research report sponsored by the United States Department of Defense. All very serious indeed.
But all very useless indeed as well. Merely three years later that report, Mr. Finkelstein realized what the rest of the industry took fifteen years more to figure out; that the CMMI model was incomplete, and that most software organizations required three more levels below the lowest CMMI classification. Hence the proposed “lunatic” (level -2), “stupid”, and “foolish” (level 0) levels, to complete the CMMI-provided “initial” (1), “repeatable”, “defined”, “managed”, and “optimising” (5) ones.
The ad-hoc and chaotic processes followed by organisations at Level 1 can, by dint of exceptional individual and team effort, produce software. Level 0 foolish organisations act in such a way as to prevent this effort bearing any fruit. (…)
Only by a miracle can a Level -2 organisation produce any useable software. As Level -2 organisations rarely get beyond specification they pin their hopes on automatically generating a program from that specification.
The truth is that most software organizations, unfortunately, are still better described using the 22 year-old allegory of The Big Ball of Mud.
A Way Forward
As stated previously in this article, we software practicioners “laugh at the bar” about these anecdotes. We must not. This is a serious problem, which has palpable effects in our society through the release of dysfunctional software, and it is the opinion of this author that this situation cannot continue any longer.
In spite of all of its merits, the whole Agile thing (and its most recent offspring, the famous DevOps) is not enough to improve the current situation. You are not going to have better software products by valuing the items of the left more than those of the right. Those are good principles, but nothing else. Neither is a “correct application” (whatever that is) of Scrum, Kanban or Crystal going to solve this conundrum.
I am not suggesting that developers should earn an MBA (although that could certainly be useful). However, reading books such as the following will help them understand the actual difficulties of running a business under real-world constraints: “The Ten Day MBA” by Steven Silbiger, “The Personal MBA” by Josh Kaufman, “Eric Sink on the Business of Software” by Eric Sink, “Becoming a Technical Leader” by Gerald Weinberg, “The Manager’s Path” by Camille Fournier (reviewed by Graham in this month’s issue), and “Leading a Software Development Team” by Richard Whitehead.
I am not suggesting managers should learn computer science (although that could certainly be useful). However, reading books such as “Geekonomics” by David Rice, “The Phoenix Project” by Gene Kim et al., “The Mythical Man-Month” by Fred Brooks, “Peopleware” by DeMarco & Lister, and “Agile” by Bertrand Meyer will undoubtedly give them some useful perspective.
(Alternatively, you can follow this very publication, and maybe even contribute to it, one objective of which is to build bridges between these two seemingly disparate worlds.)
The underlying message to software developers is this one: rolling your eyes in front of a business representative is not going to help anyone. Sit down, listen, and understand. Running a business can be as challenging as making that algorithm as efficient as possible, or to find a viable workaround to that stubborn, badly documented API from your vendor.
A similar message to business managers is: do not take “The IT Crowd” as an example in management. The IT staff should not be relegated to the basement, because your “digital transformation” (whatever that is, and whatever shape it takes) requires you to have the “tech guys” on board, and to be taken into consideration.
The current impossible dialogue must become possible at all costs. This dialogue requires respect from both sides, a skill that cannot be acquired by reading books alone, however.
Let us not hold our breath for a revolution. So far, Sociocracy and Holacracy seem more like evolutions than revolutions in the field of management. The establishment is not yet ready to shake the status quo of how, when, by whom, and where work is to be performed yet, and will likely not be ready for change for quite a few decades, still.
That leaves us to think, with all pragmatism, that the best software in the years to come will be a byproduct of a healthy interaction between tech-savvy managers together with business-aware software engineers. The cross-pollination of both areas of expertise, by team members aware in both sides of the equation of the needs and constraints of the other, is the only formula we have at the moment for software teams to grow and improve.
Cover photo by the author.
