The Future of Software Development

Whar are YPU doning in the future?

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

These thoughts just came together yesterday, but fundamentally they’re a result of working on agile projects some years. Here and there I’ve seen tendencies of the things I’m going to write about. Ready? Let’s go for a ride into the future, because in the future…

…There’s no Scrum

Scrum will have taught us that it’s a good idea to have a prioritized list of things to work on and one or more people responsible for keeping that list up-do-date and aligned with the business objectives. Scrum will also have taught us that delivering in short iterations reduces both technical and business risks and provides yet another level of feedback. We’ll also know that synchronizing our efforts at short, possibly daily intervals is a good thing to do. Finally, there will be more retrospectives, not only in the development team, but in other parts of the organization as well. All these things will likely be around, but we’ll just do them without calling them by fancy names.

Will there be Scrum Masters or people in similar roles? Maybe, maybe not. We’ll certainly acknowledge that some ways of working are better than others, so we’ll need very little process guidance. Since we’ll be acting more autonomously, any member of a team will be able to address impediments. If one contact surface will be required, any member of the team may fill the role (as it happens today in teams with rotating Scrum Masters).

…There’s no Kanban

If not now, then at least in a couple of years we’ll realize that doing too many things at the same time is a bad idea. Why did we start to take on too many things at the same time at the cost of thrashing and excessive multi-tasking again? We’ll also realize that in a stressful situation, only a few things are of truly critical importance.

Visualizing production flow along with its bottlenecks will be common practice, not only in software development. In fact, our future workplaces will be more visual. We’ll visualize our designs and architecture, goals, and stories currently being worked on. The term “information radiator” will not be used. It will be internalized. We’ll want our surroundings to radiate information at us all the time, and we’ll certainly contribute to keeping it current, as opposed to hiding it in documents on a Sharepoint site.

…There’s no test-driven development

We’ll wonder: “What were our reasons for having an entire profession in which some people (developers) produced an artifact, but didn’t accept responsibility for its functionality and handed it over to another group of people (testers) to verify that it worked?”

Testing and verification will be around, especially in complex domains, life-critical systems, or areas regulated by laws, but checking will not. Testers won’t do mind-numbing checking and run the same scripts over and over again; for such activities will have been automated long ago.

We’ll remember the days of monolithic monster methods, too risky to touch, too risky to change, with little sorrow and nostalgia. It will be obvious to developers that code written with test support makes them faster and their jobs more interesting and challenging. Instead of committing to eternal code-fix cycles, developers will be able to spend their time delivering new features in new technologies they like; as opposed to being bogged down with legacy code chained to an obsolete technology stack.

…There’s no continuous delivery

Instead we’ll ask ourselves: “What is non-continuous delivery? Is it Discrete delivery?” The ability to deliver tested and integrated software whenever we want to will be taken for granted. There will be no holy test and staging environments that some hero set up once and nobody dares to touch (for they’d break anyway). That databases should be synchronized using automated versioning schemes and the provisioning of environments automated will be obvious. We’ll look back thinking: “Did we do all of this manually? Didn’t that waste an awful lot of time? And did it sometimes take hours to deploy stuff to production because of all manual magic tricks? Wow! Did we get any development done at all, or were we just combating our environments?”

…There’s no BDD-like methodologies

In the future, we’ll have realized that incomplete specifications, vague requirements, and various incarnations of organizational whispering games cost just as much as monolithic legacy code, if not more. Actually, there’ll be less time for rework. Our competitors will make sure of that.

When looking back, it will be quite apparent that documents with fancy sweeping general terms mixed with words like MUST and SHOULD failed to target pretty much everybody in the development team, even their authors. We’ll understand that the quickest and safest way to produce requirements is to have the various stakeholders, technical and non-technical, talking to each other and agreeing on concrete things illustrated with actual examples. No inconsistencies, vague language, or missing cases.

We’ll also be quite puzzled by the fact that a specification document written by one person or team used to be handed over to developers for one interpretation and testers for another. We’ll wonder how much time it took to make the interpretations of this document meet in the final tested product, and how much rework it required. And how did we handle these documents if they weren’t connected to the tests and code?

So what is there in the future?

Dear reader. If you’ve read this far, you have realized that many of the relatively new, semi-cool practices and techniques that some organizations are still struggling with to get in place will be internalized and become second nature. Many practices and techniques that we’re still calibrating today will be at the core of our profession.

Why do I dare to make these claims? Because, I’ve seen glimpses of the future I’m describing in various organizations, and I can tell you that there’s no going back. Try hiring a developer who has worked on a team that has succeeded with continuous delivery and tell him/her that your deployment pipeline can’t be automated because of organizational structures and rigid division of labor; that only system administrators may touch the server and only the DBAs the database. Or try making a tester working on an agile team in close collaboration with both the customer and developers go back to writing test cases from incomplete requirements and executing them manually in project sudden death. Or try making anybody who has worked in a truly collaborative environment to go back to versioned Word documents that are being emailed back and forth. These people will not work for you. They will work someplace else, and whatever that place is going to be doing, it’s going to be doing it faster with equal or better results.

11 responses on “The Future of Software Development

  1. Great post Alexander, and I agree!
    But don’t you think that there will be new cool names on new ways of working in ten years? Do you really think that Scrum, Kanban et. al. are the last process inventions that will be made (for software development)?

    1. Of course there will be new cool names! Our industry has a tendencyy of reinventing itself every decade. Scrum will be called “Rugby”, Kanban will be called “Banzai”, and continuous delivery “Express Integrated Releasing v3.0”. Wisdom will get lost, and we’ll be selling these things.

      And of course do these methodologies and techniques not represent the peak of what we can do. However, it would be kind of nice if they formed an unspoken baseline for new ideas to grow on.

      Even in the future will we need names for new achievements, to distringuish them from the old stuff if not anything else, but I’d rather want our industry to make some advancements (even if they come with fancy names).

  2. Good Post Alexander. One more thing that I believe will be part of the future is truly “plug and play” software components. Software from multiple vendors would seamlessly integrate based on a universal framework. We would wonder why the people in the past had so much trouble getting softwares to talk to each other and had those huge integration projects.

  3. Hi Hrishikesh,
    I’m glad you liked the post. Regarding plug and play components… It’s true that there have been problems with making them talk to each other in the past. Well, personally I’m not sure whether that’s where we’re headed, but it’s a nice topic for a post 🙂

    1. Hello Jugal,

      Thanks for reading! You’re absolutely right. Much of this boils down to a lean approach, but I guess it should have been mentioned by name somewhere in the text.

      /Alexander

  4. Wow, well spoken! Yeah, we’ll internalize the stuff we’re good at, and make up new buzz words for the next bunch of things that we suck at 🙂

  5. Hey Alexander,
    Thanks for putting together this post on the future of software development.It is a great read. I particularly find your thoughts about the future really interesting.
    Keep up these insightful posts.

    Cheers!

  6. Thanks for this great post!

    Today, computer programming is quickly becoming the new literacy.

    There are so many fields now that require some basic form of programming. Accounting, trading, marketing, publishing, you name it – computer programming has reached that field, or soon will.

    It would be wise to institutionalize programming as a basic foundation of education; Taught right along side math and language.

    The innovations in software engineering have made leaps and bounds. We have specialized programming languages that reduce programming complexity while increasing product flexibility. We will continue to invent new languages which will make human-to-computer communication even easier.

    All the best
    Brain IT Rate

Leave a Reply to Alexander Tarnowski Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.