We have mislabeled our effort

Whether waterfall or agile or anything in between, the past forty years have demonstrated that software development demands a different perspective than preceding human endeavors. I am loathe to call software development “production” or “assembly” or any of the other words conventionally used to describe 19th-century production.

Our failure to correctly identify the “what” of software development precludes our inability to define the “how.” Therefore, we now suffer from dual, simultaneous failures and all participants carom from gutter to gutter, bumper to bumper in an out-of-control (and often slow-motion) collision of misgiving, opinion, threat, bluster, terror, and even sometimes competence. And yet, we rarely succeed through anything other than sheer will of the dedicated, highly-experienced, and most skilled technical leadership.

If a straight line is the shortest distance between two points, software development always turns out to be the longest. I used to believe our long march resulted from ignorance, but now I’m starting to believe it’s through design. If we lived in chaos, we could have expected different kinds of outcomes; but we always experienced the same kind. We always built what should not have been built. Our software never worked the way we wanted. And nothing worked together.

It is a mistake to keep doing what has failed; thinking that a new kind of personality can accomplish what the old personality did not.

Do not mistake my recollections as those from a waterfall project. I remember those like that, too, but my most painful recollections were from the agile projects and methodologies. Whether waterfall or agile, we always had the same chaos. Disparate teams only fail in the same ways when there’s a plan, from the start, to fail.

That plan, I conclude, came from unprepared, inexperienced, and unskilled leaders who feared admitting their incompetence more than they feared failure. They knew that we needed a different approach. We still do.

The What

We edge closer to finding the “what” of software development. Incremental approaches to software development allow us to see what we’re building and judge it against the dreams of the customers. We senior developers can also add a lot to that discussion. Software, while structured, has no fabric. Every materiel element in software remains virtual. We must embrace and adapt our software definition to leverage this virtual nature while eschewing the managerial reflex to treat everything like a tangible product.

We tried building software like we build bridges (waterfall). It didn’t work. We tried building software incrementally, but we’re still thinking like a production floor with designers and managers and cheerleaders and customer and builders all within view, but still spread out like we’re building bridges. I’m sure the intent is to maintain skills (organizational and authority) of the past. But I think this is our destruction. All vestiges of the past must be evaluated and, if failing, we must eject them.

We’re still a long way from finding the “how” of development for the same reasons. If we adopt the idea that software has little or no tangible plans, we could also leverage an approach to software development that rejects the reflex to deliver a product. In fact, software development delivery is an outcome, not a product.

An Outcome!

If software development is an outcome, the existence of product managers, product owners, and product designers disappears. There is no “product.” Anyone or anything involved in that “product” that doesn’t exist, should not exist, either. It simply fades away because, in reality it never actually ever existed. The whole thing was a mirage.

But what of the outcome? This still demands things the technicians now how to produce: compiled language, organized data, exposed access points, efficient, pretty and ergonomic interfaces, and many supporting documents, inventions, repositories, and annotated histories of the development experience.

We Take On More

But if our effort defines a virtual outcome, those who understand the pathways to those outcomes become the most likely participants to inhabit the formerly-external duties of software development. These additional duties borne by the technical experts now include:

• administration
• leadership
• decision-making
• communication (intern and extern)
• planning
• and delivery

These represent unorthodox duties for technical experts but we’ve demonstrated that inclusion of external non-technical players usually leads to problems of both priority and communication, as well as hidden political/business agendas that destroy development groups and poison motivation.

It is a mistake to keep doing what has failed; thinking that a new kind of personality can accomplish what the old personality did not.

We’ve never tried growing our technical experts into the kinds of administrators and leaders necessary for positive outcome delivery in software development. The Agile Manifesto says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” It adds, “The best architectures, requirements, and designs emerge from self-organizing teams.” But only professional managers insulted Agile enough to define the environment (processes) and the look of self-organization. They, again, were wrong.

A simple perspective arises: We can train technical people to administrate, organize, and lead technical groups far easier than we can train non-technical people the technology of software development.

We must attempt this. We must endeavor to take the best technical people, train them in their innate leadership styles, teach them to organize and administrate development in such a way that has a common language with non-technical business members, and then endow them with the same authority any other manager or administrator possesses.

This is the “environment and support they need.” This is the “trust … to get the job done.”

Anything less is lip-service.