This chapter is from the book
This chapter is from the book
This chapter is from the book
(Re)Thinking Software Strategy
Focusing on thinking and rethinking before the more technical bits is advisable. Until we understand what strategic business goals must be pursued, we shouldn’t try to specify system technical characteristics. After some thoughts on thinking and rethinking, introducing system-level planning will have meaning and purpose.
Thinking
Known as the source of many quotable quotes, (George) Bernard Shaw made this statement with regard to thinking:
I suppose that you seldom think. Few people think more than two or three times a year. I have made an international reputation for myself by thinking once or twice a week.
Of course, we all think every day. Life would be impossible without thought. Yet, Shaw’s entertaining statement exposes an interesting fact about people in general. Much of life is conducted in routine function and regularly employs a kind of autopilot. The less people need to think about specifics, the less they will tend to think consciously about what they do. This is why older people tend to lose cognition unless they remain mentally engaged into their later years. Shaw shows that deep thought by even the most notable among thinkers may not occur that often. Rightly, then, a lack of deep thought is a concern even among knowledge workers.
The problem with knowledge workers going on autopilot is that software has little tolerance for mistakes, and especially mistakes left unaddressed for long periods of time. If individual software developers aren’t careful, they will become lax in paying debt in their software and transition into the mode of allowing unregulated growth and using repeated, expedient repair.
There is also a concern that developers will begin to increasingly rely on what product companies want to sell them, rather than thinking for themselves in the context of their business focus. New technology buzz and hype are pumped in from outside with much more frequency than is possible from internal business channels. However, the constant drumbeats are missing the context of what matters most locally. Developers who have become complacent may wish for technology to solve the problems. Others will simply long for new toys to engage their minds. Likewise, the dynamic underlying the Fear of Missing Out (FOMO) is not driven by deep, critical thought.
As Figure 1.7 highlights, thinking a lot about everything involved in system specification is essential in making proper business decisions, and later the necessary supporting technical decisions. Here are some motivation checkers:
What are we doing? Perhaps poor-quality software is being released as a means to meet a deadline. This doesn’t put the teams in a good position to refactor later, and chances are strong that refactoring is not planned. It’s possible that the team is pushing for a big reimplementation using a newer, more popular architecture as a solution. Don’t overlook the fact that those involved have already failed to introduce a helpful architecture into existing systems or allowed a lapse in maintaining the architecture that was already in place.
Why are we doing it? External messages based on selling products as solutions may sound more attractive than taking sensible steps to shore up existing software that has lost its reason for existing in exchange for simply keeping it operational. FOMO and CV-driven development can become a stronger motivator rather than practicing good development techniques. Be certain that a particular architecture or technology is justified by actual business and technical needs.
Think about all the things. Every single learning must be examined with critical thought, both for and against. Having a strong opinion and talking the loudest is proof of nothing. Thinking in an informed manner, clearly, broadly, deeply, and critically are all extremely important. These can lead to deep learning.
)
Figure 1.7 Be a leader in thought. Think a lot and discuss.
Seeking deep thought kicks off our real mission, which is rethinking our approach to software development that leads to strategic differentiation.
Rethinking
The ancient Hippocratic Oath6 is said to have included the statement “First do no harm.” This seems relevant not only in medicine but in other fields, including software engineering. A legacy system is just that—a legacy. Legacy implies value, something that is inherited. After all, if it didn’t have value, it wouldn’t be a legacy; it would be unplugged. The system’s continued and broad use is what makes it irreplaceable at present. As much as software professionals often think that the business doesn’t get it, the business totally gets that decades of investment into a system that has supported and still supports revenues must not be harmed.
Of course, the deep debt and entropy might not be the fault of those currently responsible for keeping a system operational, or those who highly recommend its ultimate replacement. Frankly, many legacy systems do need some help into retirement. This is especially the case when these systems are implemented with one or more archaic programming languages, technologies, and hardware created by people with great-grandchildren, or who are no longer with us. If this sounds like COBOL using an old database and running on mainframe computers, the authors won’t deny the similarities.
Still, there are other systems matching this description, such as the many business systems built on C/C++. At the time the work was done, C/C++ was admittedly a better choice than COBOL. One big advantage was the low memory footprint required by C programs, and the fact that a lot of software was being built for PCs and their 256K–640K RAM limits. There are also systems built on completely obsolete and unsupported languages and technologies such as FoxPro, marginalized Delphi, and the only-mostly-dead Visual Basic language.
The major problem with replacing a legacy system is related to losing features in the replacement process or just plain breaking things that previously worked. Replacement also happens in the face of continued legacy change—perhaps slow change, but change nonetheless. Change doesn’t necessarily mean new features. It can mean daily patches of code and persisted data. Trying to replace a moving target is like, well, trying to replace a moving target. It’s hard. This is not to mention the fact that the software is already in the condition it’s in because it hasn’t received the care it has both deserved and needed. So suddenly introducing great care as the target moves and as people are actively firing rounds at it seems iffy at best.
That a system is to be justifiably replaced using modern architectures, programming languages, and technologies doesn’t make the task any less precarious. Many conclude that jumping in and getting it over with by ripping apart the current implementation and coding up a new one is the only way to go. It is common for those championing such efforts to request several months to accomplish this feat, undisturbed by change. That request translates into halting the moving target for a number of months, and as has already been noted, the system will very likely require patches to code and data. Shall those be put on hold for an unknown length of time?
Where is the rethinking in all this? In blowing the common legacy escape hatch, it appears likely that a lot of harm will be done. It’s a knee-jerk reaction to vast problems that leads to a high probability of replacing them with immense problems or ending up with two sets of enormous problems. The Big Ball of Mud being the enterprise norm leads to competitive paralysis—but to first cause no harm, the patient must still be able to breathe if there can be any hope to perform health-restoring treatments. We need to find a way to jump into a reimplementation, but not by doing one of those cannonball dives that makes a huge splash. This requires some special anti-splash measures and maneuvers.
What hasn’t been considered is the creation of new learning opportunities. If we merely rewrite in C# a large system that was originally implemented in Visual Basic, from a strategic point of view nothing at all has been learned. One client, for example, observed in a replacement effort of a COBOL legacy system that 70% of the business rules developed over 40 years had become obsolete. These still lived in the COBOL code and required cognitive load to deal with them. Now, imagine not learning this information, but instead spending the time and the effort to translate all of these business rules from COBOL to a modern architecture, programming language, and technology set. The transformation was already a complex multiyear program without including a very large body of unnecessary rework.
Expanding our previous motivation checkers, the following questions highlight the need for vital strategic learnings:
What are the business goals and strategies? Every software feature within a strategic initiative should have direct traceability to a core business goal. To accomplish this, state (1) the business goal, (2) the target market segment (persons and/or groups) that must be influenced to reach that goal, and (3) the impact that must be made on the target market segment. Until the necessary impacts are understood, there is no way to identify the software functionality that is needed or a range of specific requirements. The tools for uncovering the strategic goals and impacts are described later in this book.
Why aren’t we doing it? There’s another important term in technology that needs to be taken into account when making strategic decisions: You Aren’t Gonna Need It (YAGNI). This term was meant to help teams avoid the development of currently unnecessary business features, and there are good reasons to do so. Spending time and money, and taking risks, on delivering unnecessary software is a poor choice. Unfortunately, declaring YAGNI has become a general way to cast any opposing viewpoint in a bad light. Using YAGNI as a trump card won’t win team loyalty or create breakthrough learning opportunities. Sometimes not implementing some features that “aren’t needed” is a mistake of enormous proportions. If a breakthrough that can lead to innovative differentiation is shot down immediately, it’s likely more a problem with the shooters’ ability to think deeply and recognize an opportunity or the loss thereof. In fact, absolutely refusing to make room for subsequent discussions will reveal the weakest thinkers in the mix.
Can we try new things? Teams might agree or disagree about what might work in their target market. It is mostly impossible to absolutely foresee the market’s reaction to a given expression of strategy. Gauging the market’s response accurately requires giving the market the opportunity to try out the business ideas. Using the science of experimentation may provide the only true way to understand the real possibilities and limitations of strategies; however, to try new things, it’s not always easy to think outside of the established mental model. “It is tremendously difficult for people to realize when they are chained to a model, especially if it is subconscious or so woven into the culture or their expectations that they can no longer see how much it is holding them back” [Brabandère].
What are the service-level requirements? Once a reasonable set of strategic business goals is understood, the teams involved can start to identify the necessary architectural decisions that must be made. The candidate architectural decisions will depend on the service-level requirements. Teams should not settle on solutions too quickly because there are often advantages in delaying decisions about some details of the architecture. For example, even if the teams are convinced that a Microservices architecture is necessary, delaying the introduction of services separated by the computing network can help the team focus on actual business drivers rather than trying to cope with the distributed computing overhead too early. (See the section “Deployment Last,” in Chapter 2, “Essential Strategic Learning Tools.”)
Rethinking is a critical step, and it feels right. There is a benefit from thinking multidimensionally and critically, and rethinking from a position of ordinary to a fresh strategic vantage point.
We need not conclude, however, that all legacy Monoliths are necessarily the Big Ball of Mud variety. While the vast majority are definitely Big Ball of Mud systems, we must think carefully before making this judgment. The point being made follows next.