The long tail of software development

One thing I try to keep in mind when starting any software project is the "long tail" of enhancements and support required for success. I suspect that it's the failure by many to acknowledge this aspect of software development that leads to the high failure rates reported by both practitioners and business owners alike.

Software engineering is a highly creative and demanding activity, and like all such professions attracts smart and creative people - the type of individuals that would rather be solving the next fun and challenging problem than focusing on all those post-launch chores like communication, support, enhancements, bug fixes, user training, and ... more communication that lead to a successful "product". (I put product in quotes here because whether you are delivering a commercial package or developing for in-house use, I believe any software solution should be treated as a product with all the attendant elements: engineering, marketing, sales, support, etc.)

Too often software engineers define success as delivering a piece of technology that resembles the customers' or product owners' original request, is mostly bug-free, and fairly stable - a pretty low bar, after which they move on to the next exciting problem. The question of adoption is left up to the customers and product owners. If the goal is a truly successful product this is a mistake!

My career has been littered with laments of "we delivered exactly what they asked for, but we can't get them to use it". Implicit in this is the attitude that the software developer can't influence success beyond delivering a sound technical solution; this is counter productive on two counts.

First, it lets technologists off the hook for the ultimate success of their creations. As a technologist, I am a card-carrying introvert; I get it. I would rather solve technical problems than talk to end-users to figure out what's keeping them from using my software, talking to managers to explain the benefits of a delivered solution, or crafting a communication (i.e. marketing) campaign. Such activities do not come naturally to technologists - but we need to get over it and either develop those skills or team with colleagues in disciplines such as Marketing or KM that are comfortable in those areas.

Secondarily, and related to the first point, failure to own the ultimate success of our work can mask fundamental technical flaws which may not be apparent immediately. Staying with the software through its full lifecycle teaches important lessons about the impact of design on supportability, maintainability, and reliability. Unless you design and build software with these three objectives in mind (IMHO) you are inviting failure, as the customers/end-users will quickly abandon your product as the frustrations mount.

The cure for these problems is simple to state but hard in practice: when considering a new software project build in a commitment to all those post-launch activities required to ensure success; from support and bug fixes to communication, marketing, training, cajoling, listening, revising, etc. that are critical to success. And don't shy away from demanding the same commitment from your end-users/product owners - if they aren't fully committed to the projects success then find those who are. Doing so can't fix a bad design, but will help ensure a good one delivers maximum value.

The range of valuable, fun, and technically challenging problems to be solved has never been greater, from AI to cloud, data science to workflow and automation, security to robotics and more, there has never been greater opportunity to add value to the market and your firms.

But ignore the long tail of software development at your projects' peril!