Thinking about predictable software development

I was talking with a mentor this week about software development and the challenges of aligning IT ideals with business expectations. From a high level we agreed that the purpose of the software development process should be to produce software that generates monetary value, by revenue increase or cost decrease, for the business. That’s really just stating alignment with the goal of the business and may seem obvious. Yet in reality, people tend to drift towards different goals for software development. That’s what creates misalignment between stakeholders and often results in inconsistent output.

One of the key principles that he wanted me to take-away was that the production of software should be predictable. A definition of predictable is “behaving or occurring in a way that is expected.” So what do business owners expect from software development? What do IT owners expect?

In my experience, an IT group tends to define predictable software through quality measures. There is a heavy emphasis on requirements to create a detailed specification with the goal that the software will do exactly what the business stakeholder requests. But business stakeholders tend to define predictability in terms of the cadence of the output. They want to have a comfort level of when something will be produced that solves a problem for a customer and ultimately generates revenue for the company.

Are the metrics of a predictable cadence and predictable quality incongruent? I don’t think so. But to achieve predictability with both of these attributes requires a different mindset from all the team members. It means that requirements may not be defined exactly according to a specification. It means software output may take multiple iterations or not be exactly right the first time. Are business leaders and IT leaders willing to live with that level of inexactness?

And does it seem counter intuitive that inexactness can provide predictability? It’s a mindset change. But I remind myself that satisfying predictability is also not the goal. It’s a means to achieve the goal to produce working software that sells and provides a monetary value for the company. That’s something everyone expects.

One Reply to “Thinking about predictable software development”

Comments are closed.