Escaping the Era of Manufacturing

But I’m just a soul whose intentions are good:
Oh Lord! Please don’t let me be misunderstood …

— The Animals

Software is eating the world, but most people really don’t understand it.

For one thing, it is relatively inexpensive to create if you are the one who can actually create it (although the opportunity cost is, of course, the kicker). But it is extremely expensive to create if you cannot. Non-makers latch onto the former, and are always shocked with the latter.

A tremendous amount of people don’t seem to realize that software is a continuous thing, at *all* stages of its lifecycle. Even a feature-fixed software product needs maintenance to deal with integration, OS, and hardware changes. Have you ever heard of a successful startup that launched its first product, and then didn’t need its design and engineering team anymore (let alone didn’t need to hire *more*)? And yet it is astounding how many people try to jump into software with the expectation that they just need to get their mobile app / website / etc launched and afterwards they’ll neither need to hire a team (the smartest option) nor keep the consultants around.

And elsewhere, it is astounding to see how many places still have not embraced agile. Or if they have, the approach is really “agilefall” where the engineers work in so-called agile cycles, but they are still working with requirements handed to designers who hand mocks to engineers. And it is all under fixed deadlines that don’t seem to change even when so-called stakeholders change their minds.

It is amazing to me that even today, after humans have now been creating software for decades, that engineers and designers are still expected to predict the future with work estimates, when there is a planet-sized body of evidence that proves they cannot.

It is bizarre to see how enterprise budgeting processes require employees to promise a fantasy. Then the rules give them little freedom to make sensible decisions that either save money or chase found opportunity. All because planning is worshipped over reality.

Pair programming is another deeply misunderstood and distrusted thing. I’m not religious about pairing, but I suspect most people think it is an excuse to have two people do one person’s job. ¬†Few understand the impact in terms of sustained focus and overall speed, which is rooted in faster problem solving and higher quality-as-you-go.

So much of the world is still stuck in a 19th and 20th century manufacturing mindset, treating software like widgets.

But software is eating the world. There is no company of any scale, or that aspires to be of any scale, that is not a software company today. It can’t be hidden in the corner. It shouldn’t be chucked around the world to low-cost labor. It doesn’t work like a Ford assembly line. It is too important for people to misunderstand it as badly as it is today.

But I shouldn’t be all doom. There is a growing body of people who do get software, and who continue to advance the art of creating it for meaningful purpose. And likely if you are here, you are one of them. I’m guilty of both preaching to the choir and repeating myself, but bear with me. Sometimes I can’t help but shake my head out loud.

  • A desire for accountability is really what drives much of the focus on planning and estimating. Even if a business stakeholder knows that the timeilne is a wild guess, at least it gives her a blunt tool for keeping the team focused on the work. Like any sufficiently complex task, software development is a bit of a black box, and managers are looking for ways to make sure developers don’t sandbag (or sandbag more). Greater accountability to a peer may be one of the biggest benefits of pair programming. A culture of accountability, code reviews, stand-ups, and other similar processes also address this challenge, but they’re all harder to use effectively than brute force schedule pressure.

    Anyway, I think this unacknowledged use case for planning and estimating drives a lot of the dysfunctional behavior in software development.

    • Yes I see it split between the financial desire for planning (understandable) and the management desire for accountability (also understandable but often misguided). The worst part is that it leads to MORE sandbagging, rather than mutual trust and best-efforts to work hard, make something meaningful, and adjust to inevitable changes with eyes open and honest acknowledgement of the impact.

      That isn’t to say that deadline goals aren’t sometimes a necessity and can’t, used correctly, be good focusing tools, but fixing both time and scope ahead of time is insanity IMO.

    • If the goal is accountability, why are sprint reviews not a better measure?

      About 7 years ago, I worked at a public company that had recently transitioned its development team of ~200 from waterfall to agile. Through this process, people previously thought to have been high performers were found to be anything but, while others not previously considered high performers shone like stars.

      If brute force schedule pressure was truly effective, one might argue waterfall would be a far more effective process. Also, agile is not agnostic of deadlines; it simply provides a greater level of transparency and forces the business to make more realistic, and informed, decisions regarding the possible.

      • I’m not saying it’s effective, certainly, but I think anxiety about accountability is often an unacknowledged driver behind “agilefall.”

        • That is the frustrating part – it’s ineffectiveness.