Some of the strongest software engineering practices may be underrepresented in public discussion, not because they failed, but because the organizations that benefit from them have little reason to explain them in detail.

When a company develops engineering habits that improve predictability, integration, quality, or assurance in ways that competitors struggle to match, those habits stop being mere process preferences. They move into the realm of strategic assets. And strategic assets are generally kept internal.

The public picture may be incomplete

Published information about software development can give the impression that the field is more transparent than it really is. Methods are discussed at length. Success stories circulate. New fashions arrive on schedule. It might seem as though anything truly effective would already be widely known.

I don’t think that follows.

Some engineering practices are easy to describe, easy to imitate, and safe to market. Others are harder to explain cleanly, harder to transfer, and much more tightly tied to the internal habits of a capable organization. If those practices produce real economic advantage, there may be little incentive to publish the sharpest details.

That does not require secrecy in any dramatic sense. Ordinary business incentives are enough.

When discipline becomes economically valuable

Some forms of engineering discipline produce local improvements and not much more. Others change the shape of execution itself.

A strong discipline can give a team a clearer technical basis for decisions, steadier evidence about what is actually true, less waste from rediscovery, and a better chance of keeping a system intelligible as people, requirements, and operating pressures change. Over time, that affects schedule confidence, defect behavior, integration risk, certification posture, and the ability to scale work without losing coherence.

At that point, discipline is no longer just an internal preference. It has become part of how the firm competes.

This matters because software organizations do not only compete on features. They also compete on whether they can make sound decisions under pressure, whether they can integrate reliably, whether they can demonstrate compliance when needed, and whether they can keep complexity from turning into self-inflicted drag. Those are not abstract virtues. They affect cost, timing, and what kinds of work a company can take on with confidence.

Why firms protect the sharp edges

Once a company recognizes that a method, architecture practice, review habit, or evidence structure gives it leverage, some form of protection becomes fairly predictable.

That protection may be explicit. It may involve confidentiality controls, restricted access, compartmentalization, internal standards, or simply a reluctance to explain too much outside the firm. In software, valuable know-how does not live only in source code. It also lives in how work is organized, how models are used, how assumptions are challenged, how evidence is carried forward, and how the organization avoids having to relearn the same painful lessons.

The interesting part is that protected knowledge is often broader than people first assume. It may include tooling. It may include architecture. It may include process. It may include the quiet discipline that makes a method effective in practice rather than merely attractive in theory.

But intentional protection is only part of the story.

Some secrets keep themselves

I suspect many firms do not hide their best practices so much as fail to recognize what they have, or fail to explain it in a way that would make its significance visible to others.

I have seen teams doing something genuinely strong without fully appreciating how unusual it was. A few understood that they had a good local practice, but did not quite see that they were sitting on something beyond ordinary competence. Others were simply too busy shipping, recovering, adapting, and dealing with the normal untidiness of real programs to step back and interpret what they had learned.

In those cases, nothing is being protected in any formal sense. The knowledge just remains embedded in practice. That alone can be enough to keep it obscure.

One of my earlier encounters with this came through a small software developer group, where I first heard a detailed presentation on the Shlaer-Mellor method. The presenter had been a project manager at a well-known telecommunications OEM, on the development of a fairly complex piece of switching equipment. His team had built their own tooling for model validation and code generation using VBA with Microsoft Visio. He had also written an article about the project for intended publication in “Communications of the ACM”, and draft copies were shared with the group.

The article was interesting partly because it was not written as a heroic account. If anything, it was introspective and somewhat apologetic. It described a team that was new to the method, the cost of training, the burden of building the tooling, and the complications of a project that had been shelved twice in favor of higher-priority work. The outcome was favorable, but the tone was measured.

What caught my attention was that the article included raw numbers, but didn’t even try to interpret them. It gave team size, hours, defect counts, and related project data. What it did not do was calculate the productivity implications.

When I ran the numbers, I was floored.

The project appeared to show roughly 100 SLOC per man-day on the production code.  For those who are unaware, lifecycle productivity in high-assurance software has long been estimated at 10 to 11 SLOC per man-day, regardless of language, for a high-performance team.  So 100 was far beyond the common rule-of-thumb productivity figures, and it came with a very low defect count on a complex commercial product.

I contacted the author to make sure I was not misunderstanding the numbers. When I told him my findings, he was taken aback as well. He had not really considered what they implied when viewed that way.  

During our discussion, I suggested that due to the nature of the tooling, perhaps about 20% of the code volume was excess, in comparison to equivalent hand-written production code.  He agreed that estimate aligned with his observations. On that basis, the more appropriate comparative accounting was probably closer to 80 SLOC per man-day; still an extraordinary result.  He talked about revising the article in light of that analysis. Although I looked for it, I never saw either the original or a revised version of the article published.  So, the unusual success of that project probably never entered the public record.

Still, that encounter stayed with me. It helped spark my long interest in model-driven development, but it also made another point that seems important here. A team can possess a very strong practice, and even have evidence of its value sitting in plain sight, without it ever becoming public knowledge. Sometimes the organization is guarded. Sometimes nobody has the time or inclination to tell the story properly. Sometimes the people involved do not fully see the broader significance of their own results.

And sometimes the secret simply keeps itself.

What this does to public discourse

If that happens often enough, public discussion will tilt toward what is easiest to market, easiest to repeat, safest to generalize, or least costly to disclose.

That does not mean the public discussion is false. There is published evidence that disciplined software processes can produce unusually strong results. The Cyberpartnership material is useful on that point, because it documents real strengths in approaches such as TSP, Correctness-by-Construction, and Cleanroom, while also making clear that such methods are not widely practiced.  The public record already contains more evidence than mainstream software culture cares to consider.

Some of the strongest engineering habits may remain internal, softened for publication, or absent from the public record altogether. Over time, that can distort perception. Methods that are easy to talk about may come to look like the ones that matter most, while methods that quietly improve outcomes may receive much less attention.

I think this helps explain why writings about software practice can feel less substantial than the realities occurring within stronger organizations. The most circulated literature may overrepresent what is fashionable and portable, while underrepresenting what is deeply effective but hard-earned, context-bound, or commercially sensitive.

That is worth remembering, especially when the loudest examples begin to stand in for the whole field.

The limits of silence

This is not an argument that secrecy guarantees a durable advantage. It does not.

Good ideas spread. People move between firms. Products can be studied. Outcomes can be observed. Competitors can imitate part of what they see, and sometimes they can infer more than one might expect. So silence is an imperfect protection, and internal discipline does not remain proprietary forever.

Still, it shapes the public picture. Incentives affect what gets published, what gets simplified, what gets branded, and what is kept close because it works well enough that the firm sees no reason to turn it into public theater.

There is another filtering effect as well. Public writing often does better when it confirms what readers already believe. Methods that can be described as lightweight, adaptive, or freeing tend to be easier to welcome than methods that sound demanding, structured, or difficult to master. Over time, that can give the public conversation a bias toward what is emotionally and culturally agreeable, not just toward what has the strongest engineering consequences.

What readers should take from this

The absence of widely publicized detail is not good evidence that disciplined methods have failed, or that stronger engineering habits do not exist at meaningful scale. In some cases, it may suggest the opposite.

The methods may be doing useful work in places that have little reason to explain themselves in public, and in other places, the people using them may not fully realize how much they have achieved relative to ordinary practice.

Some methods become popular because they are easy to describe. Others become valuable because they are hard to replace.

For software engineering, that distinction matters.