The Agility Series — 3— A New Era of Adaptable Software Development
Introduction
The world of software is quickly separating those serious about building value quickly from those who only dream of the idea. Nick Tune, a mentor of mine, is tackling this head on in his new book coming out entitled Architecture Modernization: Socio-technical alignment of software, strategy, and structure. It is proving to be an invaluable guide to set organizations up for success for those who want to achieve amazing software. This post is a mashup of my understanding of Mr. Tunes’ documented thoughts, my experience, and discussions with colleagues.
Essentially, it comes down to this. One day, if an enterprise is not capable of absorbing change in a daily or even hourly cycle, they will become a footnote in the history of this age. It does not matter how big the company is, they will fall. In fact, the old adage, “the bigger they are, the harder they fall” is appropriate in this circumstance. If the challenge was merely technical, this post and the new book Mr. Tune is writing, would not be written. The reality is, it is socio-technical. Programmers are not enough. Software Engineers are better, but not enough. Platforms and frameworks help, but are not nearly enough.
More is being written now on the process of quality software change than ever. If you need evidence, take a look at Adam Tornhill’s recent study (https://codescene.com/hubfs/web_docs/Business-impact-of-low-code-quality.pdf).
Some corporations are catching on. Others are trying, but their internal politics, lack of awareness, and deficiency in education and experience are preventing them from leveraging modernization concepts. Focus on the right things though and a company can forge their new reality before they are left behind. Waste time in 1900’s manufacturing process thinking and deadlines will soon be the last thing an organization will care about.
Crafting The New Era of Software Development
Features delivered are in the past.
Adaptable systems are the future.
Let’s explore this. In the “Age of Agile”, the focus was on moving away from waterfall software development lifecycle practices to a more iterative approach. In concept, this was a healthy evolution. In practice though, it was not achieved. The goal was to eliminate waste. Companies that understood true waste were capable of sorting through what it means to become agile at all levels. Others that did not understand what it takes to make sustainable code chose a poor route of becoming project management agile, while not adopting software agility principles. The result? Most companies tried to get as many programmers programming stories as possible. This does not work and with good reason. Developing software is not the same as digging ditches, sweeping floors, or any number of labor-intensive works. It requires thoughtful action. Most enterprise systems are not haphazardly assembled or even predictably straight forward any more than building a jetliner or a skyscraper would be. Systems need architectural capability, process design, and cognitive effort to be efficiently designed, developed, and succeed at delivering value. This flow is a sophisticated art that requires thinkers and doers. The work we do today in software needs to be pliable for the work we do tomorrow. Labor intensive work has a tiny amount of this pressure, but often nowhere near the magnitude that these more inventive pursuits experience.
In the face of tough pressure, some of the sharpest minds in software are helping companies deploy new business changes by lunch that were discovered in the morning. This is quickly becoming the new normal. Yes, their software is updated in production every hour or two. For some companies with many teams, production is an ever-changing landscape every minute. Getting there is not easy, but imagine what a team could accomplish if this were their reality. What would that take? Let’s list some of those ideas here:
1) Stop focusing on unnecessary and unhelpful change. Continually adopting the latest agile paradigm as a silver bullet or deciding that a particular technical framework is going to save the day are a couple of common missteps. Spending inordinate amounts of time on what is easy to choose is often a sign of corporate dysfunction.
2) Find every bottleneck blocking rapid discovery, design, development and education. Do what is needed to eliminate those delays. This includes the practice of coding bad software before designs are given appropriate thought. Also, forcing developers to submit their code to arbitrary reviews that are not based on business needs is unhelpful. Lean thinking is helpful in this space. Remove the waste. However, what many think is waste, i.e. design, is a speed boost when done well. Be careful with assumptions.
3) Make automation a goal at all the right places and in the right ways. Testing is a big key. Automate as much as possible, only the things you need to get code to production in reasonably safe ways. Yes. Developers should be able to confidently push the button to either stop or deploy a feature. Once you gain your composure, please keep reading.
4) Redefine your team concept. Many cultures view business and IT as being two halves of the same team. This is an error in modern times. It makes for a blame culture. They need to know, believe, feel, and operate as the same singular team — not two halves. Make a quality high-functioning team, that includes all the people required to make the software in their subdomain work.
5) Make your system appropriately modular, in a Domain-Driven Design manner, and let your teams own those modules. The more appropriate the boundaries, the more likely the team will soar with new ideas and solutions. Domain modular software is easier to build. Domain modular software is easier to test. Domain modular software is easier to deploy.
6) Stop incentivizing and promoting deadlines and other arbitrary achievements as some sort of worthwhile goal. Speed is important. But ask the hard question. Does business need the solution to allow future growth or do they need something fast? Systematic designs done well get faster, if they are well maintained and upgraded consistently. The goal is generally not to deliver a fast feature now for most organizations. The goal is the ability to deliver more rapidly over the long haul. Ignore this and you will have to rewrite your software every so often. Teams, companies, and stakeholders don’t often say this, but they think it. They want greater adaptability with more of the business need being met faster — period. Most developers can write code today to meet a deadline to get their next bonus. Not everyone can turn business objectives into an adaptable systematic design that absorbs future enhancements faster.
7) Develop an educational movement that enables greater design and innovation. This thrust should include ways to help business owners learn to communicate requirements through skills like Eventstorming. This education should also help developers learn how to move from programmer to system designer.
8) Face reality. Measure it. Accept it at face value. Resolve to improve it. Stop making excuses for poor code enhancement performance. Start planning the resolution of problematic statistics. The news is likely not good. Explaining it away to avoid grappling with it, is adding insult to injury.
9) Adopt a patient, yet persistent mental energy. Rome was not built in a day, and neither were the legacy systems that many companies are straddled with. If it took years to create the undesired state, it will likely take years to transition to the desired state in full. Don’t be dismayed though. It should take weeks or months to start driving the new value modality. Take the wins where you can and never give up.
10) Question everything. Nothing is off the table for the startup. If a mature enterprise is going to compete, they must question areas that are currently taboo. This does not mean anyone has to lose their job, but it stands to reason, if a person is doing a job that does not provide value, they need to be coached on what it means to transition their career to a role that does provide value. Focus on real impactful opportunities.
11) Face common deceptions head on. Stop believing that if a programmer is programming, they are always providing value. Stop believing that design does not provide value. Stop believing that deadlines automatically provide value. Stop thinking that all programmers have been trained to design and provide systematic solutions. Stop believing that just because a feature was programmed to work today, that it is designed to be upgraded in the future.
12) Learn Domain-Driven Design. To get moving, all of the team needs to understand their role in defining, designing and delivering adaptable systems. The Domain Expert is the tip of the spear. If they are out of alignment with the business, there will be headaches. Next, the developers need to understand these domain concepts for all the work they do. If they are out of alignment, there will be many headaches.
13) Again, Features delivered are in the past. Adaptable systems are the future.
These are just some of the ideas that I hear being pushed in the most advanced, forward-facing, and highly productive companies around the world. Most company leaders are not able to shake off the normal day to day and make effective drastic changes. However, these changes would set the company up for daily success in rapid production. Some decisions are counter intuitive, but that is the point. If they were obvious, little encouragement would be needed. Leaders may not know what changes are needed. Some leaders make simple changes to their organization. It’s the hard change that will make the difference. The tough changes require a better vision.
What does this mean for the organization that is not willing to adjust? What if they won’t believe or take action. What if they don’t muster the courage to work against the entropic nature of software development in a more skillful and domain intelligent way? Certainly, big risks are ahead.
Conclusion
Daily and hourly deployments of valuable changes are not a pipedream in the software pipeline anymore. A few companies are embracing this concept every year. They may even be your competitors! One day, this will be the only way software is deployed. The risk of delay is so great that it could mean the decimation of the organization not willing to face this new challenge.
This post should serve not only as a warning, but also as an encouragement because organizations are able to facilitate changing needs through systematic design, not just develop immediate needs. This is a hopeful message that even though it takes commitment, vision, and leadership, it can be accomplished. Today is the day to engage in this change, because the new era is happening now.
Resources For the Journey
Nick Tune, a luminary in the industry with experience deploying rapidly and safely is about to publish a book, Architecture Modernization: Socio-technical alignment of software, strategy, and structure, published by Manning, that has many more insights. His knowledge of DDD and history of assisting organizations uniquely positions him to provide deep levels of insight in this space.
Vladik Khononov, a brilliant mind, has developed ways to better consider design. His books Balancing Coupling in Software Design: Successful Software Architecture in General and Distributed Systems and Learning Domain-Driven Design are great resources.
Adam Tornhill, a forensic scientist turned technical genius, has a tool called “CodeScene” that highlights real issues with code quality from a Domain-Driven Design perspective.
And there are many others who contribute to this body of knowledge not the least of which are Eric Evans and Alberto Brandolini. Keep learning and let’s search for a better software tomorrow today.
Until then…
