[dasil003]

Title is a bit overblown for the actual epiphany which is more about the necessity of programmers having a robust mental model of a system to be able to maintain, let alone improve the system. I don't see anything particularly unique to software in this thesis, as complex physical systems also have the same characteristic.

I also think this is way off base:

> It means that the code base we create is not the true product of our work. The real product is the mental theory of that code base which

This is manifestly not the case. The value of computers is that you can write code once, and the computer can execute it repeatedly ad infinitum. As a programmer, your mental theory of the code base has value to its owners, but it's not the product. The code base is also not the product. The product is whatever output is created and consumed by the relevant stakeholders.

[naasking]

> As a programmer, your mental theory of the code base has value to its owners, but it's not the product

If you lost all of the code today, with the right understanding you could build it again relatively quickly. If you lost all that understanding, say all the developers quit, the program will no longer be adapted to customer needs potentially for years until that understanding is rebuilt.

I agree that "product" is probably not the right word, probably "asset" fits better. Losing that knowledge is like losing a manufacturing plant for your product. The plant isn't the product but it's a key asset for producing the product.

[redhale]

This is a great point.

At a micro level, this helps articulate why rewriting/refactoring a feature just after writing the first version of it is so quick, relatively. And why it is often easier to write better code in a second pass. The first time you had to build the theory AND the code at the same time. In subsequent passes, you have the benefit of the theory from the start.

I think this concept is self-evident to most experienced engineers, but I have not heard quite as succinct an articulation of it before.

[imheretolearn]

> If you lost all of the code today, with the right understanding you could build it again relatively quickly

Yes, but it has nothing to do with the codebase. There are 10,000 ways of building the same product with entirely different codebases.

[analog31]

Building the same product with a different codebase is virtually guaranteed to be a disaster. This is the famous "second system effect."

Sometimes the original coders are the only people who know, not only how the software works, but even what it does. Unknown uses include features discovered by users but unknown to the makers, and one-off hacks created to serve a valuable customer.

[imheretolearn]

> Building the same product with a different codebase is virtually guaranteed to be a disaster.

There is no point in going back and forth over this unless you have a real world example.

> This is the famous "second system effect."

[1] I believe you've misunderstood this effect. My understanding is that in the "second system effect", the succeeding system is not the "same" as the original

[1] https://en.wikipedia.org/wiki/Second-system_effect

[naasking]

Sure, but deviation from a known path introduces more risk. Every different technical choice at the very least may introduce unforeseen incompatibilities with previous "knowns".

[nurple]

But you might argue the fact that most software is always adding features and changes is because it really is never a perfect representation of some target theory. In that case, the theory inside the heads of each person behind the software may even be incomplete compared to some perfect representation, and the work done by a company in the user/feature iteration cycle is the process of reconciling the drift between each of them towards some shared theory.

I don't think it's uncommon for parts of the theory already enshrined in implementation to be forgotten to time as it passes, if it's not regularly revisited and cogitated on.

[dasil003]

That's an interesting point. My thought is that the theories of the software go well beyond programmers to everyone who interacts with the business process in question. Everyones theories are incomplete and aspirational though, sort of like a dream, while the code executing is the cold hard reality. Programmers have the closest theory to reality, sort of like a lucid dreamer, but even those with the deepest expertise are still subject to the deterministic outputs of code execution in production.

[TheOtherHobbes]

It misses two points.

One is that software development is collective. On any non-trivial project, it's impossible for one person to understand the entire problem domain or the entire code base.

What's being called a theory here is also collective. It's the current combined understanding of a group of people.

The other point is that code is persistent. If it's finished and the developer who created it is fired (for example, for lying to the board) it will carry on working, because the understanding it contains has been automated.

The code only needs to be understood when it needs to be changed or reinvented. And changes can often be handled with partial understanding.

The more partial the understanding the more it's likely to lead to bugs. But sometimes it can also fix bugs which the original developer included - refining the automated understanding instead of making it worse.

So... I'm not at all convinced by the OP.

[popularonion]

Seems like the author independently discovered the concept of conceptual integrity: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept...

That reminds me of a comment on HN that I had to bookmark when I read it:

> Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on.

https://news.ycombinator.com/item?id=33923682

[namaria]

Every world changing realization can look trivial from the other side. Understanding that people who don't have the amount of experience we have in our domain need to go through their own internal theory building process is both why it is so rare to find good teachers and what this epiphany is about.

> The value of computers is that you can write code once, and the computer can execute it repeatedly ad infinitum.

Until something changes and you need someone with a sound theory of the system to work out in a timely manner why it stopped working and how to get it working again. Bonus points for figuring out that this will happen again and that "running code" is not the product, the ability to keep the system running and evolving by changing code efficiently is.

[svilen_dobrev]

yeah. far from well-understood.

have a look at Phillip Armour's "The Laws of Software Process: A New Model for the Production and Management of Software, 2003" it talks about Software as knowledge medium, and effects thereof.. an attempt to put them things with their legs down, not up.

... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.

... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.

... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.

and a consequence:

"... for the most part, (software) engineers do not _know_ how to build the systems they are trying to build; it's their job to _find_ out how to do it." i.e. programmers must be able to learn (and teach) - should learn that and/or be taught to it. All else are tools supporting that activity.

[rramadass]

> ... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.

Absolutely true.

It is also true of all other disciplines of Engineering. The difference with Software Engineering seems to be that there are no Physical/Natural laws/constants to inform the Programmer of explicit boundaries/limitations and hence a stopping point.

[msmenardi]

> ...The value of computers is that you can write code once, and the computer can execute it repeatedly ad infinitum.

until, of course, someone updates a library that your code depends on or the OS changes the way it executes code or some other arbitrary change happens and your code is broken forever.

[dang]

> Title is a bit overblown for the actual epiphany

Ok, let's use that word above since the article uses it as well.