4 ms·

I'm not sure I understand the analogy. In rockets, you can either add another stage, or you can keep the number of stages the same and make your engines bigger.

by spuz 2y ago

I'm not sure I understand the analogy. In rockets, you can either add another stage, or you can keep the number of stages the same and make your engines bigger. The former allows you to shed weight somewhere along the launch while the latter does not. In either case, I'm not sure how that translates to software architecture.

pentaphobe 2y ago
Excellent point (Chin stroke): I think the key metric for insights on the web isn't whether they're accurate, but whether you can sound smart when repeating it to someone else. (Not saying I approve of this)
rco8786 2y ago
I would call it a “leaky analogy” but any analogy can be picked apart. The overall point is sound IMO. Be aware of the operational load you’re signing your team up for when choosing your architecture. Seems like commonly sense but is often overlooked.
gpderetta 2y ago
Most importantly, what's the rocket equation of software?
- dsr_ 2y ago
  Adding complexity to a late project makes it later and less maintainable. Brooks v2
- Dove 2y ago
  While I don't have a good way to articulate it, it does seem to me that the modern software development style which involves an explosion in complexity, either in terms of dependencies or infrastructure or both, in order to make developer time go a little further, and the ensuing explosion in expertise required to maintain, secure, and evolve the system... all of that does strike me as reminiscent of the rocket equation. When I find myself spending more time dealing with patching dependencies, or screws coming loose somewhere in the build system, or dealing with performance idiosyncracies of some hot new database, or the peculiarities of some middleware messaging system, or the automated tests needing maintenance, or dealing with transitioning off a now-unmaintained technology, when I find myself spending so much time doing such things that making any actual change in business logic takes orders of magnitude more effort than it should, I do very much feel like all the engineering effort is just fuel to lift fuel to lift fuel. How to articulate that in a pithy way? I do feel that when you have a lot of technologies interacting on a project, even if they all worked well together initially, in five or ten years time the whole thing does have a very rocket equation like punishing curve for return on maintenance effort. Perhaps something like "Over time, maintenance effort approaches exponential scaling with the number of interacting technologies." Ah! I got it. What's going on is that external dependencies are a source of chaos, as maintenance and security issues and expertise requirements flow from that project into yours. So... "Dependencies cause multiplicative bit rot."
HarHarVeryFunny 2y ago
It's a bit of a loose analogy, but perhaps useful all the same. It's based around his rocketry "weight adds weight" no free lunch warning. Adding an extra expendable stage will get you further, but better be sure you need it since the added weight and complexity comes at a cost that the whole rocket will have to bear. The software equivalent is adding infrastructure components to your project because on one level they help you towards the goal of what you are trying to build, but "no free lunch" applies here too, and there is a downside in terms of overall complexity, debugging times, build times, maintenance cost, etc. Maybe "no free lunch" and/or "technical debt" already express it, and we don't need a new "weight adds weight" way to describe it, although there is something about the tautological inevitability of it that is a valuable reminder.
gravescale 2y ago
I think the point is that a staged rocket is clearly "better" in theory, but adds a step-change in complexity and overhead that might not actually be required. It adds a non-zero chance that the mission fails catastrophically due to a defect in the staging system at a critical moment, or the design process overtakes the budget and the whole thing is scrapped. In either case an N-1 stage rocket may have done the job. Doubly so if you are experts already in single-stage rocketry, but lack staged rocket design and execution competence. Akin's Laws¹ of Spacecraft Design have a few relevant ones: > 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. This is not the only one that's relevant. Also 15, 27, 33, 34, 36, 36, 38, 44, and, if you substitute "distributed architecture" for "launch vehicle": > 39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program. Of course, if a staged design is actually required (and not just because your engineers need to buff their CVs so they can jump out when the project fails under its own weight): > 41. There's never enough time to do it right, but somehow, there's always enough time to do it over. ¹: https://spacecraft.ssl.umd.edu/akins_laws.html https://spacecraft.ssl.umd.edu/akins_laws.html
alanbernstein 2y ago
A couple generous interpretations: Sometimes "throwaway work" is still worth doing. Maybe you can spend one month hacking an important feature into the old architecture, to deliver it early while investing 6+ months of work into The Right Way. Deprecating the first version is like dropping a rocket stage. Adding architectural complexity leads to growth in developer headcount. This requires more support staff, and more communication complexity. The growth follows a superlinear trend, as does the fuel requirement for larger rockets.
halfcat 2y ago
The analogy seems more clear to me in IT operations. Let’s say we have one server running our stuff, and it’s too slow. One option is, upgrade the CPUs or add more RAM. This seems analogous to “build a bigger engine” in your example. There’s no added complexity (well, mostly, maybe you run into NUMA issues or something). But some kinds of upgrades are more costly or complex than they appear on the surface. If we want to add 1 TB of usable storage space, at the physical level that means multiple drives for redundancy, keeping multiple copies of the data for backup, keeping replicated copies of data that are ready to turn on at any moment, and so on. So in the developer’s mind we think “add a single 1 TB drive”, but in reality it might take adding 15-20 drives in numerous servers to accomplish this. The same thing happens when going from a single physical server to multiple. With a single server you can scale vertically. But horizontal scaling is a different type of complexity, now having to think not only about server redundancy, but redundancy at the network layer, now you need redundant network switches, and it all needs to be configured right to handle any part in the communication path failing (server down, server network card down, server network card port down, bad network cable, network switch down, network switch port down), and all of those require some configuration and protocols, and maybe you’re not familiar with VRRP or LACP on the network switches and also how those interact with VMware load balancing and failover, so now you need a VMware person and a Cisco person and that’s not even considering how you handle split brain scenarios where both servers are still running but can’t talk to each other due to a network partition. And that’s all a very different kind of upgrade than slapping more RAM sticks in the server and keep rolling.
fifilura 2y ago
Anyone with some KSP hours tracked will understand. Thinking about my poor heavyweight rocket that barely makes it to orbit and when I compare them to the sleek elegant designs by Scott Manley that makes it to Mun and back and. Sigh.

by spuz 2y ago

pentaphobe 2y ago

Excellent point (Chin stroke): I think the key metric for insights on the web isn't whether they're accurate, but whether you can sound smart when repeating it to someone else. (Not saying I approve of this)

rco8786 2y ago

I would call it a “leaky analogy” but any analogy can be picked apart. The overall point is sound IMO. Be aware of the operational load you’re signing your team up for when choosing your architecture. Seems like commonly sense but is often overlooked.

gpderetta 2y ago

Most importantly, what's the rocket equation of software?

dsr_ 2y ago
Adding complexity to a late project makes it later and less maintainable. Brooks v2
Dove 2y ago
While I don't have a good way to articulate it, it does seem to me that the modern software development style which involves an explosion in complexity, either in terms of dependencies or infrastructure or both, in order to make developer time go a little further, and the ensuing explosion in expertise required to maintain, secure, and evolve the system... all of that does strike me as reminiscent of the rocket equation. When I find myself spending more time dealing with patching dependencies, or screws coming loose somewhere in the build system, or dealing with performance idiosyncracies of some hot new database, or the peculiarities of some middleware messaging system, or the automated tests needing maintenance, or dealing with transitioning off a now-unmaintained technology, when I find myself spending so much time doing such things that making any actual change in business logic takes orders of magnitude more effort than it should, I do very much feel like all the engineering effort is just fuel to lift fuel to lift fuel. How to articulate that in a pithy way? I do feel that when you have a lot of technologies interacting on a project, even if they all worked well together initially, in five or ten years time the whole thing does have a very rocket equation like punishing curve for return on maintenance effort. Perhaps something like "Over time, maintenance effort approaches exponential scaling with the number of interacting technologies." Ah! I got it. What's going on is that external dependencies are a source of chaos, as maintenance and security issues and expertise requirements flow from that project into yours. So... "Dependencies cause multiplicative bit rot."

HarHarVeryFunny 2y ago

It's a bit of a loose analogy, but perhaps useful all the same. It's based around his rocketry "weight adds weight" no free lunch warning. Adding an extra expendable stage will get you further, but better be sure you need it since the added weight and complexity comes at a cost that the whole rocket will have to bear. The software equivalent is adding infrastructure components to your project because on one level they help you towards the goal of what you are trying to build, but "no free lunch" applies here too, and there is a downside in terms of overall complexity, debugging times, build times, maintenance cost, etc. Maybe "no free lunch" and/or "technical debt" already express it, and we don't need a new "weight adds weight" way to describe it, although there is something about the tautological inevitability of it that is a valuable reminder.

gravescale 2y ago

I think the point is that a staged rocket is clearly "better" in theory, but adds a step-change in complexity and overhead that might not actually be required. It adds a non-zero chance that the mission fails catastrophically due to a defect in the staging system at a critical moment, or the design process overtakes the budget and the whole thing is scrapped. In either case an N-1 stage rocket may have done the job. Doubly so if you are experts already in single-stage rocketry, but lack staged rocket design and execution competence. Akin's Laws¹ of Spacecraft Design have a few relevant ones: > 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. This is not the only one that's relevant. Also 15, 27, 33, 34, 36, 36, 38, 44, and, if you substitute "distributed architecture" for "launch vehicle": > 39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program. Of course, if a staged design is actually required (and not just because your engineers need to buff their CVs so they can jump out when the project fails under its own weight): > 41. There's never enough time to do it right, but somehow, there's always enough time to do it over. ¹: https://spacecraft.ssl.umd.edu/akins_laws.html https://spacecraft.ssl.umd.edu/akins_laws.html

alanbernstein 2y ago

A couple generous interpretations: Sometimes "throwaway work" is still worth doing. Maybe you can spend one month hacking an important feature into the old architecture, to deliver it early while investing 6+ months of work into The Right Way. Deprecating the first version is like dropping a rocket stage. Adding architectural complexity leads to growth in developer headcount. This requires more support staff, and more communication complexity. The growth follows a superlinear trend, as does the fuel requirement for larger rockets.

halfcat 2y ago

The analogy seems more clear to me in IT operations. Let’s say we have one server running our stuff, and it’s too slow. One option is, upgrade the CPUs or add more RAM. This seems analogous to “build a bigger engine” in your example. There’s no added complexity (well, mostly, maybe you run into NUMA issues or something). But some kinds of upgrades are more costly or complex than they appear on the surface. If we want to add 1 TB of usable storage space, at the physical level that means multiple drives for redundancy, keeping multiple copies of the data for backup, keeping replicated copies of data that are ready to turn on at any moment, and so on. So in the developer’s mind we think “add a single 1 TB drive”, but in reality it might take adding 15-20 drives in numerous servers to accomplish this. The same thing happens when going from a single physical server to multiple. With a single server you can scale vertically. But horizontal scaling is a different type of complexity, now having to think not only about server redundancy, but redundancy at the network layer, now you need redundant network switches, and it all needs to be configured right to handle any part in the communication path failing (server down, server network card down, server network card port down, bad network cable, network switch down, network switch port down), and all of those require some configuration and protocols, and maybe you’re not familiar with VRRP or LACP on the network switches and also how those interact with VMware load balancing and failover, so now you need a VMware person and a Cisco person and that’s not even considering how you handle split brain scenarios where both servers are still running but can’t talk to each other due to a network partition. And that’s all a very different kind of upgrade than slapping more RAM sticks in the server and keep rolling.

fifilura 2y ago

Anyone with some KSP hours tracked will understand. Thinking about my poor heavyweight rocket that barely makes it to orbit and when I compare them to the sleek elegant designs by Scott Manley that makes it to Mun and back and. Sigh.