3 ms·

Your comment struck a chord with me from what I've seen in various enterprise codebases, and it also seems to have a flywheel effect. That is, it's possible fo

Your comment struck a chord with me from what I've seen in various enterprise codebases, and it also seems to have a flywheel effect. That is, it's possible for a small team of experts to keep a piece of software in a constant good, small state by always balancing additive vs subtractive solutions, because everyone has a fairly complete model of the entire project in their head. But if there is any tendency towards additive solutions (e.g. due to personnel churn, deadline crunch, etc), the project becomes larger and thus harder to keep a model in one's head. This makes subtractive solutions harder to think of and implement, which results in more additive solutions, thus exacerbating the problem.

spondyl 6y ago
Given your comment, you'd probably really enjoy Peter Naur's "Programming as Theory Building" since it's effectively heading down a similar path of thought: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf The gist of it is that when a small team builds a piece of software, they have a theory (or I suppose a mental model by another name) of how it exists (either the literal files on disk or a rough abstraction of the "shape" it takes) and an understanding of the strengths and weaknesses of its design. One team may share the "theory" of the program with another by adding a new team member, they learn from osmosis (not just the codebase but the insights from other members). In reality, what often happens is that a team erodes through attrition or even is entirely removed from a project. The new team who takes over it, has no theory of how the software works and has to form an entirely new theory. That theory may be mismatched to the realities of the environment it lives in (infrastructure assumptions, cultural assumptions and so on) which can make additions even worse. I suppose I imagine it like the statue of David that gets created in Spongebob only for the weird, out of place squidward nose to be tacked on it like it works but it doesn't seem quite right and you can almost point out the line. Anyway, it's an interesting conundrum since there's not really an easy way to express this concept to big bloated corporations who think they can just exchange one contracting firm for another, and not end up with a mish mash hell contraption that shits all of their customers. The natural fix might feel like having sole indies running a project where the mental model is not in jeopardy (sans being hit by a bus) although I would think it's more in the range of 10 people or so but I honestly haven't gotten far enough to test that out yet :) Additionally, you could say that documenting not just the software itself, but the assumptions held at the time would work. It probably would help but that assumes future developers will read it (some will find a rewrite the only logical course because they don't understand the project, or the language etc) while others may just be under business pressure to "move as fast as possible" which gets mistaken for "writing code" instead of understanding what came before.
CobrastanJorji 6y ago
I'm afraid there will almost always be a tendency towards additive solutions for maintaining existing products simply because nobody will endorse removing features that some customer wants. I'm afraid that an existing product can only add and add further features until a new, slimmed down competitor appears and begins hoovering up most of your customers.
jka 6y ago
Agreed, it resonates here too. There's probably a little of the "No one ever got fired for buying IBM" mindset[1] in here, somehow. Engineers, product managers, executives, and consumers alike probably all _tend_ to have a slight bias towards seeing new features as a good thing, for whatever reason. And even the second-order perception of that bias ("we should probably consider adding this feature, because I think my manager would prefer that we add more features") probably compounds into this problem. Prioritizing staying up-to-date, simple, bug-free, and in-line with user requirements might lead to better results; achieving and managing that in practice is a whole separate story. [1] Footnote: not making any claim about the accuracy of this quote :) But it could illustrate the point somewhat, if the prevalance of the quote has, over the years, led to more sales for IBM.

spondyl 6y ago

Given your comment, you'd probably really enjoy Peter Naur's "Programming as Theory Building" since it's effectively heading down a similar path of thought: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf The gist of it is that when a small team builds a piece of software, they have a theory (or I suppose a mental model by another name) of how it exists (either the literal files on disk or a rough abstraction of the "shape" it takes) and an understanding of the strengths and weaknesses of its design. One team may share the "theory" of the program with another by adding a new team member, they learn from osmosis (not just the codebase but the insights from other members). In reality, what often happens is that a team erodes through attrition or even is entirely removed from a project. The new team who takes over it, has no theory of how the software works and has to form an entirely new theory. That theory may be mismatched to the realities of the environment it lives in (infrastructure assumptions, cultural assumptions and so on) which can make additions even worse. I suppose I imagine it like the statue of David that gets created in Spongebob only for the weird, out of place squidward nose to be tacked on it like it works but it doesn't seem quite right and you can almost point out the line. Anyway, it's an interesting conundrum since there's not really an easy way to express this concept to big bloated corporations who think they can just exchange one contracting firm for another, and not end up with a mish mash hell contraption that shits all of their customers. The natural fix might feel like having sole indies running a project where the mental model is not in jeopardy (sans being hit by a bus) although I would think it's more in the range of 10 people or so but I honestly haven't gotten far enough to test that out yet :) Additionally, you could say that documenting not just the software itself, but the assumptions held at the time would work. It probably would help but that assumes future developers will read it (some will find a rewrite the only logical course because they don't understand the project, or the language etc) while others may just be under business pressure to "move as fast as possible" which gets mistaken for "writing code" instead of understanding what came before.

CobrastanJorji 6y ago

I'm afraid there will almost always be a tendency towards additive solutions for maintaining existing products simply because nobody will endorse removing features that some customer wants. I'm afraid that an existing product can only add and add further features until a new, slimmed down competitor appears and begins hoovering up most of your customers.

jka 6y ago

Agreed, it resonates here too. There's probably a little of the "No one ever got fired for buying IBM" mindset[1] in here, somehow. Engineers, product managers, executives, and consumers alike probably all _tend_ to have a slight bias towards seeing new features as a good thing, for whatever reason. And even the second-order perception of that bias ("we should probably consider adding this feature, because I think my manager would prefer that we add more features") probably compounds into this problem. Prioritizing staying up-to-date, simple, bug-free, and in-line with user requirements might lead to better results; achieving and managing that in practice is a whole separate story. [1] Footnote: not making any claim about the accuracy of this quote :) But it could illustrate the point somewhat, if the prevalance of the quote has, over the years, led to more sales for IBM.