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.