Usually I don’t mind some whimsical features on a personal site, but this one is obnoxious and completely kills my desire to actually read the post (the subject of which had me intrigued).
It’s like the page design thinks the author’s content is less important than information about random visitors browsing the page. If your web design doesn’t consider the article to be worth reading, I’m not going to read it.
I feel the same about a lot of news sites that overlay the content with pop ups and ads and whatever. If the article isn’t even important to you, what am I doing here? I want my money back.
Well, this is a rare case of a professional-looking site rendered completely useless thanks to a single design decision made for no apparent reason at all.
For everyone talking about the notifications at the bottom:
After the page has loaded, use “reader mode” in your browser. Most browsers have this. That shows you only the text of the post, and not the notifications on the bottom.
If you want to communicate that point to me, turn off epilepsy mode on your site. Perhaps my life will be worse for never knowing the point the author is making. Fine. My life is also, definitely better for not tolerating this kind of cancer.js. There are a lot of good articles out there I can read instead of this one that don’t try to punch me in the eyeballs.
I left and came here to see if I was the only one that couldn’t read it because the constant movement was too distracting. I’m not going back just to do work arounds for a problem that shouldn’t exist in the first place.
I did that for about 4 seconds. Then reconsidered, and decided such a user hostile website wasn’t worth my time or attention and I left. It’s not my job to make the website usable.
Most of us power through small inconveniences as a normal part of life, calculating that it is not worth missing out on potentially valuable information/experiences/people/work/etc simply on the principle of not being mildly inconvenienced.
Eh. There is so much good content around, why waste my time reading and encouraging user hostile content? Pushing myself through inconveniences like this carries a tang of self abandonment.
Visually filtering this stuff out is really exhausting for me. I have the mental energy to read one article with buzzy BS, or maybe 3 other articles which might be just as good or better and respect my attention. I must admit - I didn’t think of reader mode. But by the time I started holding my thumb over the bottom of the screen, overwhelm had already started to set in a little. I was frustrated and the seeds of hatred had sprouted in my heart for the author. “Mildly inconvenienced” my arse.
It’s Sunday and I choose to enjoy my life. Somehow I think I’ll survive not reading this one particular article. At least not today, Satan.
Look the popup is bad, but consider he probably usually gets way less visitors, so in testing it’s probably not that bad for him. Maybe a few per article usually, but with hacker news it blows up.
Let’s not roast the guy too much, we’re all human and like cool stuff. This would be cool with a little more work, I think.
Also, the article is great. It puts together a definition for the theory of what software is in a succinct way. Software is code, but any specific software is an artifact of the theories in the developers brains. Makes a lot of sense to me.
Disagree. Writing a blog post is like getting on stage. You need to come on stage with a dream that you’re going to dazzle the audience with your show. Your blog is so interesting that it’s worth the time to read it!
If you doubt yourself so much that you think some gimmicky notifications are more interesting than the article, you’ve lost me as an audience. Why even have the content if you believe someone from Texas being on the page too is more interesting than what you wrote? If you think that, just make that. Don’t invite me to a show then halfway through interrupt your own show with something else. The idea alone gives me adhd. Stop it.
> You need to come on stage with a dream that you’re going to dazzle the audience with your show. ... If you doubt yourself so much that you think some gimmicky notifications are more interesting than the article, you’ve lost me as an audience.
I'm sorry, I just have to laugh at the self-seriousness of this and the other negative takes in this thread.
It's a quirky little "fun" feature that shows the location of other people viewing the site, implemented on a personal blog. If you have a blog that gets a few dozen views a day, it could be neat. If you get the HN hug of death, it's extremely annoying.
The author made a mistake, but it's a minor one, and I think it hardly betrays the self doubt you seem to be reading into it. It's not like it's an auto-playing video ad.
It's a good article. I suggest powering through to use the reading mode of your browser.
I got here, read the comment threads and thought, "Why is everyone going against HN guidelines to toss out low effort comments about the site design? How bad can it be?"
Then I went to the page. So distracting. I just closed it and agree with everyone else. I'd recommend the author get rid of that.
I think the theory encompasses the software itself as an artifact and also the details not included in the software like the problem domain’s details which constrain the software but might not need to be included in the software explicitly.
The model of the software might only encompass the specific ways in which the software is written explicitly, in order to understand how it operates in a near vacuum.
It's not quite the same. A model is something that you ought to be able to communicate. Theory is something internal, that you can't fully introspect, but you have and you use.
That is doubtless true for the type of people who frequent Hacker News (mostly computer programmers). But in some other communities, the word 'theory' is commonly used in the same manner as Gilbert Ryle uses it. The author of this article is apparently unaware of that fact.
> The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.
In the text above word "theory" are used instead of "understanding". Not sure why.
Anyway, what exactly the hell Im doing in the last 10 years supporting legacy system mostly without documentation...
> when all the people who have a theory of a given program stop working on it. It dies.
This is only true of software of a particular level of complexity. For the most part, it simply isn't true. Humans made it (who also would routinely forget details about their own project) and humans can understanding it enough to build a working theory. If you can perform tests for something, you can deduce what it's doing, although the business case of why or specific experience with other approaches resulting in failures is often not recoverable by deduction.
The word "theory" is used because an essential aspect of this particular kind of understanding is that it lets you reason about the domain and the code's behavior. It's an apt term in that context.
I’m not the author, but my sense was that the word theory was being used because it was it couldn’t be explained fully. An “understanding” would instead but potentially full known and documented or made into an API, etc. This theory idea is to hint that there are even bigger ideas than can’t be written and you have to feel them and learn them from the original team to use them well yourself.
I’d love to hear from the original author how they think theory compares to a mental model. The biggest different is theories are known to be wrong, which fascinates me as an idea!
I have seen many pieces of code only make sense for a moment in time. The theory was right then, but wrong as the business evolved. Or sometimes visa-versa where the business was wrong, but the code worked beautifully for it.
You've been re-building the theory in your mind for the last 10 years. A better word for theory (I would propose) is mental model.
In fact, as soon as your mental model of the system is complete enough, you might as well re-implement it. It will be easier to understand and maintain.
While it's true that systems tend to be documented poorly, I think the article downplays the value of good documentation. Good docs describe everything that went into the system, from business requirements to implementation details, including things that were tried and abandoned (either because they didn't work or because business requirements changed), including code changes (e.g. "changed from DB table to in-memory array for speed; may need to change back if array grows too large").
This historical documentation, including historical codebase (think Git repo), is highly valuable. True, a new developer without the institutional knowledge is at a disadvantage, but that's the entire point of good code and good docs: so the next devs can pick up as efficiently as possible if/when they're called in.
> The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours.
This already has a term: "derived meaning". Derived meaning is what's actually created and stored in your head, and represents your particular brain's understanding of... something. It could be a thought, it could be a procedure, it could be a memory, it could be an emotion. But it can't be transferred to other brains; you can only hope that, by communication, you can reach some form of mutual understanding that at least fits the communication.
For reference I think this probably partly explains my reluctance to use A.I. to help me code.
If I ask e.g. ChatGPT to just code something for me then the code it outputs is a black box, and there is no 'theory usage' in the parlance of the article. [Or I guess I'd have to recover the theory from the code it writes].
I've accepted by now that I'm putting myself at a disadvantage by not using A.I.
at work however. Maybe another way to think about it would be that A.I. allows us to use our higher level theoretical understanding when we interact with codebase.
What seems to work quite well is, you ask the AI to build something that fulfills your requirements. Then you ask questions about the implementation until you understand it in detail. Meanwhile you ask it to improve portions of the code based on your insights and your results after trying it out. So the black box morphs into a mental model that the machine has helped you to attain.
Copyright law protects computer programs as the expression of an idea. One idea has many expressions. If you want to modify or extend it, you need to know the idea.
[webpage text follows]
Even though I don't respect podcasts as an information delivery system, I recently listened to a podcast that felt like having an epiphany.
The podcast in question was episode 61 of Future of Coding. It is essentially a read-through/review of two papers with which I was unfamiliar, but which I believe are actually quite famous and influential.
Why did listening to this feel like an epiphany? Well, I suddenly felt like I understood what the deal is with software. Why is it that when you join a company, the engineer who's been there for years seems like an incredible genius? Why do some teams that I've been on struggle while others manage to get everything right? Why is everyone always so keen to rewrite things?
The two ideas that the podcast expresses are:
The concept of what a “Theory” is, according to Gilbert Ryle.
That being a programmer is doing “Building theories” in the Ryle sense of the word.
Having these two ideas explained together was really helpful. If I had read Ryle by himself, I would have thought, “interesting and useless”. If I had read Programming as Theory Building without knowing the theory concept, I would just not have understood.
I recommend listening to the podcast and reading the paper. But if you don't want to do that, I'm going to try and explain the two points.
strange
What is a Theory, According to Gilbert Ryle?
When Ryle says theory, he doesn't mean anything like what other people mean when they say theory. Annoying. He should have just come up with a new word. What he means is the thought object that exists in our minds which allows us to do things.
I, for example, know how to cook pasta. When I cook pasta, that's a certain expression of this knowledge. When I try and explain to you how to cook pasta, that's a different expression of it. Neither of those expressions contains everything I know about cooking pasta. And in fact, there are parts of what I know that I can't really express in any way. This knowledge is what Ryle would call a theory. I have a “Theory of how to cook pasta”. This theory is not something that exists in language or action - it’s a something that we can never fully express. The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours.
What Does it Mean that Programming is Theory Building?
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:
Allowed us to create it in the first place.
Allows us to diagnose problems with it and fix them.
Allows us to modify it easily.
If I think about times when I've worked on a team that works well and gets stuff done, it's been a team where:
Someone has been there for a long time, since the start of whatever code base/feature we work on.
Other team members have joined slowly, and had a chance to work with the people who know more.
The area of focus does not change. We haven't been reassigned to a random existing project, or asked to fix some other team’s work.
The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.
This model explains a few curious phenomena:
What “legacy code” actually is - it’s a code base which is no longer maintained by people who have a theory of it.
The solo engineer who can make a better product than a team of equally competent professionals. The solo engineer has spent the...
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.
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.
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.
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.
> 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.
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.
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.
> 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
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".
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.
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.
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.
> ... 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.
> ...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.
The “software as theory” idea is helpful - thanks OP. Right now I’m dealing with some devilishly difficult GPU code, and I now understand that I’ve been working to reverse engineer the authors’ theory from their code. With much effort, I achieved a gratifying epiphany, and the code suddenly became clear! (Perhaps I developed a theory related to but not identical to that of the original authors.) Fortunately, I have an enlightened manager, and he was patient with the “theory building” process. Software degrades to garbage when a series of successive developers apply changes to it without a cogent theory. The process is self-reinforcing; the more degraded it becomes, the harder it is to develop a useful and accurate theory.
“ The process is self-reinforcing; the more degraded it becomes, the harder it is to develop a useful and accurate theory.” This is a really good point I think.
It feels like the Sprint / Agile practices that a lot of us use lead us to value expediency more than anything. So we'll try and find the quickest way to make a change that gets an existing program to do what we want. If we lack a working theory of the codebase that usually means we're doing something that runs counter to the overall design. And then over time everything gets worse and harder.
If it becomes, or is deemed, necessary to have, or recover, a theory of an implementation of an automation, then you have already lost. What is necessary is the theory of the business. If you do not have that -- and practically no one has that -- then your automations are towers of guesswork, and there is no way to determine whether they are correct.
Nuked the notification stream with UBlock: `##section > ol`
It's an interesting observation on the reason behind something that's understood fairly well in management circles from its impact: Retention of software engineers is really important!!!
I never really had a conceptual model for the period in a project where I can't really effectively write code outside of exploratory exercises. Building a theory of the solution to a problem is absolutely the most difficult part of any project that I've worked on.
In brownfield projects I will usually start out with a
manual linting pass. I read code deeply enough to understand it to a point where I feel like I can make delinting changes to it. This helps me build up a theory of the solution space that those who came before me, the act of delinting, commiting, and pushing stands as something of a mental proxy for having written the code myself.
Greenfield projects are much more difficult as you have to synthesize this theory from whole cloth rather than learn it by reading the musings of coders that came before. IMO, this is incredibly valuable as very few devs I've met have the capacity, even if they have the experience.
In many ways I think that past successes in founding companies is used as a proxy signal for this skill by investors when making a bet on a venture by tenured tech founders.
> Greenfield projects are much more difficult as you have to synthesize this theory from whole cloth
This is the reason why Domain knowledge (or access to a Domain expert) is so very important for Programmers. Without that knowledge you cannot build a "theory" and then map it to a "solution domain model".
133 comments
[ 2.9 ms ] story [ 187 ms ] threadBut having this on the HN frontpage, there are tons of visitors right now and this is indeed annoying.
I feel the same about a lot of news sites that overlay the content with pop ups and ads and whatever. If the article isn’t even important to you, what am I doing here? I want my money back.
With this nonsense "someone in Timbuktu just connected" nobody benefits. It's just 100% annoying and dumb.
It is that bad. I did not read the page.
After the page has loaded, use “reader mode” in your browser. Most browsers have this. That shows you only the text of the post, and not the notifications on the bottom.
Or, read a copy of it here:
https://web.archive.org/web/20231118211242/https://johnwhile...
If you want to communicate that point to me, turn off epilepsy mode on your site. Perhaps my life will be worse for never knowing the point the author is making. Fine. My life is also, definitely better for not tolerating this kind of cancer.js. There are a lot of good articles out there I can read instead of this one that don’t try to punch me in the eyeballs.
Maybe his theory of his software was that only a few people an hour might be likely to visit his site.
You should really just read the article, it’s short and good.
I expect that 99% of the time it's a perfectly fun little pop up, but right now with the post on HN it is amazingly annoying
Most of us power through small inconveniences as a normal part of life, calculating that it is not worth missing out on potentially valuable information/experiences/people/work/etc simply on the principle of not being mildly inconvenienced.
And this is a VERY mild inconvenience.
Visually filtering this stuff out is really exhausting for me. I have the mental energy to read one article with buzzy BS, or maybe 3 other articles which might be just as good or better and respect my attention. I must admit - I didn’t think of reader mode. But by the time I started holding my thumb over the bottom of the screen, overwhelm had already started to set in a little. I was frustrated and the seeds of hatred had sprouted in my heart for the author. “Mildly inconvenienced” my arse.
It’s Sunday and I choose to enjoy my life. Somehow I think I’ll survive not reading this one particular article. At least not today, Satan.
Let’s not roast the guy too much, we’re all human and like cool stuff. This would be cool with a little more work, I think.
Also, the article is great. It puts together a definition for the theory of what software is in a succinct way. Software is code, but any specific software is an artifact of the theories in the developers brains. Makes a lot of sense to me.
If you doubt yourself so much that you think some gimmicky notifications are more interesting than the article, you’ve lost me as an audience. Why even have the content if you believe someone from Texas being on the page too is more interesting than what you wrote? If you think that, just make that. Don’t invite me to a show then halfway through interrupt your own show with something else. The idea alone gives me adhd. Stop it.
I'm sorry, I just have to laugh at the self-seriousness of this and the other negative takes in this thread.
It's a quirky little "fun" feature that shows the location of other people viewing the site, implemented on a personal blog. If you have a blog that gets a few dozen views a day, it could be neat. If you get the HN hug of death, it's extremely annoying.
The author made a mistake, but it's a minor one, and I think it hardly betrays the self doubt you seem to be reading into it. It's not like it's an auto-playing video ad.
It's a good article. I suggest powering through to use the reading mode of your browser.
Then I went to the page. So distracting. I just closed it and agree with everyone else. I'd recommend the author get rid of that.
(I think I'm the only on-topic comment so far.)
The model of the software might only encompass the specific ways in which the software is written explicitly, in order to understand how it operates in a near vacuum.
In the text above word "theory" are used instead of "understanding". Not sure why. Anyway, what exactly the hell Im doing in the last 10 years supporting legacy system mostly without documentation...
This is only true of software of a particular level of complexity. For the most part, it simply isn't true. Humans made it (who also would routinely forget details about their own project) and humans can understanding it enough to build a working theory. If you can perform tests for something, you can deduce what it's doing, although the business case of why or specific experience with other approaches resulting in failures is often not recoverable by deduction.
Why, why they used word "theory" in the first place?
I’d love to hear from the original author how they think theory compares to a mental model. The biggest different is theories are known to be wrong, which fascinates me as an idea!
I have seen many pieces of code only make sense for a moment in time. The theory was right then, but wrong as the business evolved. Or sometimes visa-versa where the business was wrong, but the code worked beautifully for it.
This historical documentation, including historical codebase (think Git repo), is highly valuable. True, a new developer without the institutional knowledge is at a disadvantage, but that's the entire point of good code and good docs: so the next devs can pick up as efficiently as possible if/when they're called in.
https://www.partykit.io
This already has a term: "derived meaning". Derived meaning is what's actually created and stored in your head, and represents your particular brain's understanding of... something. It could be a thought, it could be a procedure, it could be a memory, it could be an emotion. But it can't be transferred to other brains; you can only hope that, by communication, you can reach some form of mutual understanding that at least fits the communication.
If I ask e.g. ChatGPT to just code something for me then the code it outputs is a black box, and there is no 'theory usage' in the parlance of the article. [Or I guess I'd have to recover the theory from the code it writes].
I've accepted by now that I'm putting myself at a disadvantage by not using A.I. at work however. Maybe another way to think about it would be that A.I. allows us to use our higher level theoretical understanding when we interact with codebase.
The podcast in question was episode 61 of Future of Coding. It is essentially a read-through/review of two papers with which I was unfamiliar, but which I believe are actually quite famous and influential.
Why did listening to this feel like an epiphany? Well, I suddenly felt like I understood what the deal is with software. Why is it that when you join a company, the engineer who's been there for years seems like an incredible genius? Why do some teams that I've been on struggle while others manage to get everything right? Why is everyone always so keen to rewrite things?
The two ideas that the podcast expresses are:
Having these two ideas explained together was really helpful. If I had read Ryle by himself, I would have thought, “interesting and useless”. If I had read Programming as Theory Building without knowing the theory concept, I would just not have understood.I recommend listening to the podcast and reading the paper. But if you don't want to do that, I'm going to try and explain the two points.
strange What is a Theory, According to Gilbert Ryle?
When Ryle says theory, he doesn't mean anything like what other people mean when they say theory. Annoying. He should have just come up with a new word. What he means is the thought object that exists in our minds which allows us to do things.
I, for example, know how to cook pasta. When I cook pasta, that's a certain expression of this knowledge. When I try and explain to you how to cook pasta, that's a different expression of it. Neither of those expressions contains everything I know about cooking pasta. And in fact, there are parts of what I know that I can't really express in any way. This knowledge is what Ryle would call a theory. I have a “Theory of how to cook pasta”. This theory is not something that exists in language or action - it’s a something that we can never fully express. The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours. What Does it Mean that Programming is Theory Building?
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:
If I think about times when I've worked on a team that works well and gets stuff done, it's been a team where: The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.This model explains a few curious phenomena:
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.
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.
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.
Ok, let's use that word above since the article uses it as well.
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.
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.
Yes, but it has nothing to do with the codebase. There are 10,000 ways of building the same product with entirely different codebases.
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.
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
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
> 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.
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.
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.
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.
It feels like the Sprint / Agile practices that a lot of us use lead us to value expediency more than anything. So we'll try and find the quickest way to make a change that gets an existing program to do what we want. If we lack a working theory of the codebase that usually means we're doing something that runs counter to the overall design. And then over time everything gets worse and harder.
It's an interesting observation on the reason behind something that's understood fairly well in management circles from its impact: Retention of software engineers is really important!!!
I never really had a conceptual model for the period in a project where I can't really effectively write code outside of exploratory exercises. Building a theory of the solution to a problem is absolutely the most difficult part of any project that I've worked on.
In brownfield projects I will usually start out with a manual linting pass. I read code deeply enough to understand it to a point where I feel like I can make delinting changes to it. This helps me build up a theory of the solution space that those who came before me, the act of delinting, commiting, and pushing stands as something of a mental proxy for having written the code myself.
Greenfield projects are much more difficult as you have to synthesize this theory from whole cloth rather than learn it by reading the musings of coders that came before. IMO, this is incredibly valuable as very few devs I've met have the capacity, even if they have the experience.
In many ways I think that past successes in founding companies is used as a proxy signal for this skill by investors when making a bet on a venture by tenured tech founders.
This is the reason why Domain knowledge (or access to a Domain expert) is so very important for Programmers. Without that knowledge you cannot build a "theory" and then map it to a "solution domain model".