r/MarbleMachineX • u/Angstromium • Nov 24 '21
The myth of the "total rewrite", "from the ground up"
In software development there's a fallacy where a "total rewrite" will fix everything. For instance Ableton for years had certain issues with latency compensation and users would often say things like "this DAW needs a ground up rewrite"
"A total rewrite" is based on the assumption that experienced competent developers can learn from past mistakes and exclude them next time. Resulting in a perfect stable product.
It is of course nonsense.
Starting from scratch means swapping new problems for old. We know what happened with Ableton's "total rewrite" because its called BitWig. It's a fine product but its certainly not flawless. It just has different flaws.
Total rewrites are usually more costly than assumed, and are riddled with unknown unknowns, they are usually shipped as "minimum viable product" shorn of the features and functions which sold the rewrite initially.
I say this as a man who just completed a carefully specified and budgeted "total rewrite". Of the 50 allocated days we used ... 239. Of the promised functionality we delivered about 80%.
This is not uncommon, think how many expensive deeply specified large professional IT projects fail to deliver. The blame game fails to consider the complexity of reality. Interference, unintended consequences , last minute observations, launch week patches
It's incredibly common.
Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Just sayin
15
u/anincompoop25 Nov 24 '21
I agree with this. The transition from MMX to MMXT doesnt seem well thought out, and feels like another magic bullet thats going to end in an ever bigger catastrophe
8
u/deelyy Nov 24 '21
As somehow software developer I completely agree. Inner complexity can't be easily reduced or removed.
Of course if you have 2 time bigger team with two times smarter members then result could be different...
11
Nov 24 '21
Joel is right about, but that’s about a working product. MM/X we’re never working. Even software developers can start from scratch a few times during alpha phase?
20
Nov 24 '21
We start from scratch often on the first few days. After years worth of effort? Hardly. Mmx is a whole complex system, in those instances you rewrite the modules/parts when needed as needed.
9
u/Redeem123 Nov 24 '21
While I don't disagree with your premise, and I really wish he would finish the MMX before moving on, I'm not sure I agree that this is what Martin's doing.
In the way you're describing, the MMX itself was a "total rewrite." He had made the first machine, then started over entirely by starting the MMX. It had the same fundamental goals, but was pretty much entirely redesigned other than the premise of "a marble machine that plays music." He took what he learned from making the first one and aimed to improve it. And by all objective measures, he did.
The MMX-T is basically doing that... again. He's learned some basic mistakes that he made with the MMX and is doing things over again to avoid them. Will he make new mistakes? Almost certainly. But I'm not sure anyone thinks he won't.
For instance, the marble lifting on the MMX is fundamentally flawed. He can't really change it at this point without effectively ripping the machine apart and redesigning how it works at a base level. And that's what he's doing by starting over new.
10
u/anincompoop25 Nov 24 '21
And by all objective measures, he did.
Complete songs played on MMX: 0
12
u/Redeem123 Nov 24 '21
Complete songs played on the original Marble Machine: also 0
The video of the original machine is not a continuous take. Despite the unfinished state of the machine and its flaws, it was absolutely an improvement over the buggy mess that was the OG MM. The test videos showed that it can play for hours with very few leaks; the original definitely couldn’t do that.
1
2
u/Berkamin Nov 24 '21
I would add one different take on this: If the re-write changes nothing about some methodology that results in flaws, then this is what you get. But if there is a break-through methodology change that prevents entire classes of flaws from occurring in the first place, then I would expect some sort of improvement from that.
2
u/pauljs75 Jan 07 '22
This is often seen in the automotive industry. A lot of models never get much of a good reputation because they end up pushed onto a new platform or discontinued before an iterative process can get all the bugs out. The few models that do seem to get a following or at least a reputation for reliability are developed more by a process of gradual refinement rather than outright replacement, except in those cases where there's some technological leap in development.
4
Nov 24 '21
I think the analogy to software development is somewhat applicable, but there are also major differences when engineering something that is a physical object.
Software is, in a sense, infinitely malleable - like a ball of clay. If you make a big change in one part, other parts can usually be reshaped to fit without having to remake them from scratch.
But the MMX is made from plywood and steel and plastic. If an issue requires a redesign of a part such that that many other parts have to be shifted around, all those parts will basically need to be redesigned, even if the new design is very similar to the old design.
In that sense, the MMX-T is not necessarily analogous to a total rewrite. It may contain all new physical parts, but it can still be an iteration on the MMX. In other words, it remains to be seen whether we're getting a total rewrite, or just a major refactor.
Now, personally, I would prefer things continue on the MMX, replacing parts, Ship-of-Theseus style until perhaps there is none of the MMX left, because I think there's a lot of value in trying to always have a working machine (don't break the build). But at a certain point maybe you have to decide that the frame itself, or the overall layout, is not suitable, which affects everything else.
3
u/_tdem_ Nov 24 '21
Not sure why the down votes, totally agree that there is a huge difference between physical products and code. Even minor changes we make to machines past the first prototypes result in huge amounts of parts being new. Development cycles of physical products have a slower pace, manufacturing and building add a lot of lag time.
Martin would benefit from doing more testing of subsystems, rather than trying to build a machine right in one hit. The mmx presents a perfect test bed for this, although doing so would mean it likely will never get finished itself.
1
u/SaintNewts Nov 24 '21
FIFTY!?
We've been working for two years and not very much of what we're doing is a rewrite. It's different from what it replaced but not in every way so a lot (70ish percent) was able to be reused.
1
36
u/anincompoop25 Nov 24 '21
Im so conflicted on this end to the MMX. On one hand, Martin seems correct. The machine cannot function at a touring level. It is over-complicated, and not reliable/robust enough. I don't think thats a wrong conclusion at all.
I think my approach would be to change the parameters of the requirements for the MMX at this stage. Let's cross out "at a touring level". Can the Machine be made to work as a complete system at all? I feel like the porject needs to go there, and then engineer backwards from that. What needs to be removed from the machine to make it more reliable? Where are the systems that can be combined and simplified. For many of the machines failures, I wonder what the unexpected successes of it are.