Dec 112014

A good way to make predictions is to recognize current trends and then extrapolate them into the future. The longer the trends, the more confident you can be about the predictions. Thinking about software development processes, we see two long-term paths that software development has taken. These paths are the basis of both our joint prediction for the coming year and the kind of holistic consulting we will focus on in 2015.

The path some have taken has been moving from one lifecycle process to another, each containing a set of prescribed practices. These, in rough order, are waterfall, spiral, controlled iteration/RUP, Xtreme Programing, Agile, and DevOps. We may have missed one or two, plus some of these have several flavors. It is fair to say that in some ways each process has emerged based on lessons learned — what works and what doesn’t — from its predecessors and so there has been evolution of sorts. What these processes have in common is that they have or had a set of adamant practitioners whose mantra is “Trust the process. If you follow it correctly it just works. If you are not getting good outcomes, you are not doing it right.”

There is another, parallel path some in our field have been taking: The borrowing of operational and management techniques from adjacent fields. These include standard project management (critical path analysis, earned value management) from civil engineering; system thinking from system engineering; lean (Kanban, value stream mapping) from factory operations; measurement from 6-sigma; predictive analytics from decision analysis; and software economics (capitalization, cost/benefit analysis) from economics. And recently, Donald Reinertsen has continued this trend by comparing development to both the Internet and autonomous military teams to develop 175 principles.  Over the years we have been learning how software differs and how it is similar to the adjacent fields from which these techniques have been borrowed. The mantra of the people who promote these principles is “Understand and internalize the principles and apply them intelligently to software.”

One disadvantage of the first path is that it is too prescriptive. There is enough variation in software development that blindly following even a sound process will often, but not always work. A weakness of the second is that it asks too much of the practitioners. Software developers want to develop software, not become experts in all these fields so they can pick and apply the right principle.

So now the prediction: We predict these two paths will converge. As our field matures, we will have to adopt and apply the lessons learned from the adjacencies. There is too much wisdom there to ignore. At the same time the need for prescriptive guidance will not go away. So a new kind of prescriptive framework will evolve, one that is more menu-driven, reflecting the variations of software development. This framework, a mashup of the lessons learned from the adjacencies, will provide a way to input the characteristics and challenges of your development effort and provide guidance on which practices to consider and how to apply them. This framework might not be fully in place by the end of 2015, but we will see an acceleration of the confluence already taking place. For example, in 2014 we have seen some movement in applying lean techniques to agile and devops. There are other examples involving systems thinking and analytics filling in the gaps of agile. These convergences will continue in 2015, setting the groundwork for a fully integrative framework to emerge in 2016.

[Editor’s Note: This post is part of the annual “Cutter Predicts …” series.]

Don’t miss Israel Gat and Murray Cantor’s workshop “The Best of All Worlds: An Integrative Framework for Software Development” at Summit 2015, where they’ll flesh out this prediction and help you see how this integrative framework, coupled with the iterative nature of Agile that makes data-driven learning — and reacting — possible, sheds light on the opportunities for your organization to develop better software.


Murray Cantor

Murray Cantor is a Cutter Consortium Senior Consultant. He has been applying leading-edge ideas in software and systems development for more than 30 years. Until recently, Dr. Cantor was an IBM Distinguished Engineer, a member of the Rational CTO Council, and the Rational Lead for Analytics and Optimization for Software and Systems.


  6 Responses to “A New Kind of Software Development Framework”

  1. […]  follow-the-recipe and apply-the-principles approaches to development. You can find our prediction here. Please take a look. We will expand on this prediction at the upcoming Cutter […]

  2. What bothered me about your pridiction, is that it didn’t account for the “need” of certifications. Then I thought SAFe.

    Do you think SAFe is a positivive indicator of convergence? It is the Turducken framework, taking and wrapping a little of something everyone/anyone likes (vegans and vegetarians excepted) AND has a certification program to prove to others that it has training and “rigor” and tool support.

    As predictions go, this is a little hard to measure. Care to speculate the percentage market use for different frameworks for 2015, 2016 and 2017?

    Nice article.


  3. avatar

    Hi Larry:

    Good hearing from you. If we do not have the opportunity to meet each other before the holidays, have a fantastic holidays season and a great new year!

    I am sure Murray will share his thoughts when he has a few minutes. Following are my reflections:

    Being a prediction, we made no attempt to be comprehensive. Rather, we focused on being directionally correct.

    Naturally enough, our data set is our own Cutter engagements as well as those of the 40+ Agile consultants in the practice. While opinions in the practice vary, certification is not very important usually to our clients. We do certify whenever a client asks for it, but that does not happen so often. The reason IMHO is that the vast majority of our clients look for a custom tailored solution, not for a standardized solution.

    SAFe is very intriguing. I would say Dean (Leffingwell) has clearly demonstrated that he is solving a real problem. As I have personally known Dean since 2002 or 2003, I have absolutely no doubt that he thought very thoroughly about his solution for the problem. All in all, I am very impressed with what he accomplished.

    Having said that, I do not know that SAFe is an indicator of convergence. Over the past 5-6 years I have been exposed to about half a dozen frameworks. SAFe IMHO is representative of this vintage of software frameworks.

    I believe Al Shalloway’s research and analysis since Agile 2014 is an indicator of convergence to come. I do not want to speak for Al, but from various posts, email and conversations with him I have no doubt that he “drives” in this direction. It will be very intriguing to attend his/Net Objectives’ all-day webinar tomorrow.



  4. avatar

    Hi Troy,

    As I was working on this post, I did put some thought whether SAFe was an example of the sort of convergence we are predicting. Israel and I have not discussed this, but it seems that we have come to similar conclusions independently. SAFe, in my mind, is an example of a set of follow-the-recipes methods built on lessons from previous methods.

    As we move forward, I intend to keep SAFe in mind. We do not want to build another SAFe, but come up with a lighter-weight approach that strikes a new balance between follow the recipes and apply the principles. This will be a long journey.

  5. […] website, describing our recent thoughts on the future of development frameworks. Please click here. We will be describing this at length at the upcoming Cutter […]

  6. […] website, describing our recent thoughts on the future of development frameworks. Please click here. We will be describing this at length at the upcoming Cutter […]

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>