Why Software Hasn’t Worked for You

This article is meant, not primarily for the software developer or project manager, but for the strategically qualified and motivated business professional. Its goal is to challenge the status quo of business software development and introduce an approach that may appear as novel in most enterprises. This approach focuses on delivering critically distinguishing solutions that are intended to propel business toward greater commercial success.

Clearly software has worked. We have reached the point in time when it is said that “software is eating the world.” Why, then, do I assert that software hasn’t worked? Please re-read the title carefully, and put the emphasis on Worked for You.

Although software has worked, internal software development probably has rarely if ever truly worked for you. Software that works for you renders the best achievable result by successfully delivering on your strategic business vision. How is such an ultimate result measured? Without argument, software that works for you works in your behalf the way you expect it to work, and even better than expected.

Think of a team of brilliant business minds, and imagine that they work for you. This is a team that nearly always drives incredible profit. The team has the deepest insight into your unique business, never producing failed strategic direction. You probably attempt to surround yourself with such people, or you yourself are one of them. The point is that this team oozes prosperity potential, and it delivers on its capacity.

Now, say that this “team” is your software.

Not all software in your enterprise holds the same degree of prominence. Most software is, although necessary, not business defining. Such individual solutions have the responsibility to perform a set of obligatory tasks, but possibly do not do so particularly well. Even so, the overall lackluster accomplishments are not show-stoppers, even if they are only tolerable.

Yet, a more limited array of your business software assets must be distinguishing, driving your business toward a superior economic and even socially admired position. It is from this constrained set of distinguishing software solutions that we want to reach the best achievable results. Tolerable, in this case, is intolerable.

Figure 1 shows that strategic software tops the prominence layers, being the software that deserves considerable investment. The figure also implies that non-core software does not deserve the same investment.

Figure 1: The layers of software prominence in an enterprise. Strive for the strategic.

Have you and your company fallen into distasteful servitude to your software, where you uniformly adjust your business vision and operations to fix them in place with the realities of the delivered solutions? Rather than seeing software development as a profit center, perhaps it is only sensible and realistic for you to regard it as a cost center.

If so, your software is not working for you.

Where the Promise of Software Goes Wrong

There have been several movements to try to improve on the way that software is specified and developed, the most contemporary being agile and lean methods. Used correctly agile and lean can be very effective. Yet, even with the help of various agile and lean tools, your software development process can still lack strategic communication channels. Often times software development efforts are so focused on the minutia that they fail to consider what is strategic: what differentiates your company from all others, and what doesn’t. How are preexisting software assets reused to solve new challenges? How should a full system solution be divided into smaller subsystems in order to ensure that there is a clean separation of duties? Looking again at Figure 1, while the layers don’t show subsystem boundaries, they do indicate that there are clearly defined responsibilities between prominence levels.

There are also problems with communication toward the level of the minutia. Assuming that there is some outgrowth of strategic planning for your software, however formal or informal, think of how the actual software feature and value specifications are conveyed from the top of the organization downward. Let’s use a funnel to illustrate the problem, as shown in Figure 2.

Figure 2: The vision and knowledge is broad at the top, but may have limited details as it flows down toward developers.

The “funnel of knowledge” in Figure 2 highlights the very real problems in strategically critical software development efforts. The vision and knowledge emanating from business experts is broad but may lack richness. By the time this message reaches your software developers it possibly lacks depth or lost depth of meaning and clarity. This leads to a translation of what is known by business leaders into alternate facts understood by developers. The worst case is when the alternate facts are not just slight misunderstandings, but completely wrong interpretations. This undoubtedly leads to incorrect software.

Now, assuming the situation just described, think of what happens when the software development project is in full operation: the “funnel of knowledge” gets inverted, as Figure 3 indicates.

Figure 3: All the wrong knowledge resides with the developers, and the business expert lacks traceability to vision.

As the strategic visionaries receive trickles of software implementation over time, these business stakeholders become more and more concerned and perplexed with the lack of traceability of the delivered software functionality to their original transfer of vision and knowledge. Even when corrective conversation finally takes place, it is often with the wrong people, and clarifications are commonly relayed with new confusion to the software developers. By the time the business experts and developers are in the same room, now collaborating urgently over the software’s lack of correctness, it is often too late and the conversations become adversarial. At this point making sweeping changes to the software’s business model is overly time consuming, which also means expensive.

This might be likened to a throwback to the “captain of industry era” of the latter 19th century. Someone who worked as a mere laborer might dare to exchange a greeting with the powerful president of the company. This same laborer engaging in a meaningful conversation about the strategic direction of the company, however, would be very unlikely.

Today, some business leaders have reminiscent opinions of software development and software professionals. After all, software development is just a cost center when it is so desperately needed to positively impact the bottom line as a profit center.

One of the many things that has changed since the “captain of industry era” is software. Software is eating the world, and those who don’t catch on to the need to innovate around software are going to become yesterday’s businesses. If your company is not innovating, you can be sure that your current competitor or unknown startup challenger is.

Perhaps the problem isn’t so much with the software developer, but with the way business stakeholders view the process of software development.

Fixing the Problem

Going back to the tubular communication metaphor, what would seem to make a significant positive impact on the outcome of a strategic software development effort is to have an evenly shaped conduit on both sides, as is illustrated in Figure 4.

Figure 4: Improve the communications between the business by making vision and knowledge more attainable.

Of course, there are no physical communication “tubes” in your company, so how would this work? You might attempt to accomplish this by minimizing the number of levels and relays between the business experts and the software development team. Theoretically this sounds good, but if you continue to require separation between the two stakeholder groups, you will still have misunderstandings through substandard communication that yields ambiguity.

A distant beacon may be faintly heard, but can the hearer determine whether it is directed here, or there?

Removing some layers may improve communication. Yet, rather than making borderline improvements, what if you were to eliminate all potential causes for dissenting thoughts between the two groups? This implies having not two, but one group.

If you want to have a conversation with someone, what is the best method to do so? Is it by email, or phone, or even by a video conference call? These communication methods are still “tubes.” In actuality it is a face-to-face conversation that is best. Nothing replaces the nuances in meaning conveyed even in the twinkling of an eye, a slight grin or frown, or just the intensity of a voice heard up close. (Video conferencing is the next best thing to being together.) The best way to support open and clear communications and boost collaboration efforts is to eliminate all barriers. As Figure 5 shows, bring the business experts and software developers into a cohesive, tight-knit team.

Figure 5: Complete transparency is the result of bringing business experts into a unified team with software developers.

As a result of forming a highly collaborative team of experts from both business and software development, you can eradicate miscommunication. The software developers now have the best opportunity to ingest the full mental model of the business visionaries.

This alliance isn’t limited to perfunctory knowledge extraction. Because questions arise from both sets of experts, and answers are provided openly, the result is the culmination of rich knowledge building. This leads to making implicit familiarity with the business domain formerly understood by only one or a few business experts, explicit to all involved in the software development effort. Further, the team doesn’t only search for the known knowns and the known unknowns, but it probes for the unknown unknowns. The latter leads to more noteworthy innovation. Achieving breakthroughs doesn’t mean that the team is satiated with knowledge. The business and developer members can continue unearthing greater understanding.


You may be wondering how this discussion leading to the forming of one close-knit team of business and software development experts is novel. In itself there is nothing especially ingenious about this. Still, if it is obvious, then why is it so rarely done?

There is a fundamental attitude shift that needs to take place among strategically qualified business professionals and highly competent software developers. You must collaborate as a team, or you need to prepare for the continued disappointing results of inferior software development efforts. Remember, if you aren’t innovating around software, you can be sure that your closest competitor is or will soon be.

This argument has certainly not lead to the consummate approach to software development, but we are making progress. There is more to learn about how your business can pursue a strategic approach to software, resulting in software that works for you.

More to explore

Reactive DDD: Modeling Uncertainty

Domain-Driven Design supports reactive architecture and programming. Still, reactive introduces uncertainty. Back in 2003, the way that Domain-Driven Design was used and

Scroll to Top