3 ms·
Chapter 11: Prepare to throw one away Pilot Plants and Scaling Up Chemical engineers learned long ago that a process that works in the laboratory cannot be imp
by nabla9 2y ago
Chapter 11: Prepare to throw one away
Pilot Plants and Scaling Up Chemical engineers learned long ago that a process that works in the laboratory cannot be implemented in a factory in only one step. An intermediate step called the pilot plant is necessary to give experience in scaling quantities up and in operating in nonprotective environments. For example, a laboratory process for desalting water will be tested in a pilot plant of 10,000 gallon/day capacity before being used for a 2,000,000 gallon/day community water system.
Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.
In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.[ Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.
Hence plan to throw one away; you will, anyhow.
You know the source.
- BigglesB 2y agoHadn’t thought of it in this context before but in game development a “vertical slice” could potentially be thought of as akin to the “pilot plant” in that it’s about proving out the _processes_ for creating game content (and working out how long each piece of content should take to make) before committing to “scaling up” said content production to deliver the full game…
- seventhtiger 2y agoGame development is intensely iterative. One way to think of games is software where its only value is its usability. It has has no process workflows or business goals that it ever sacrifices usability for because the user experience is the value proposition itself. It only sacrifices the user experience for other aspects of the user experience. Failed and not fun games do happen, but in general game developers put far more weight to this sort of process. There are no other goals that you can claim were accomplished if the users think the game sucks. So you get these ruthless production cycles and there's an appetite to cut things that don't work.
- piva00 2y agoFred Brooks as usual stands the test of time. It's incredible how many times I've quoted some part of Mythical Man-Month in my career, it's also part of the recommended literature I give to every junior I've trained in my life. I've noticed lately that it's become less common someone in the room has read it when I mention a passage from it, be it management or other software devs. Not sure why but it used to be much more common that I'd bring the argument against a Second-System and at least one other person would recognise it, or the issues with communication channels between a larger group. For any professional software developer out there who haven't read it, please do, it's a collection of wisdom from 50 years ago that still applies today.
- eru 2y agoIt's always amusing to read Fred Brooks' own lamentations. He's flattered that people still quote him, but also horrified that what he thought was his first, fledgling start in software project management is still quoted as start of the art. We haven't learned anything.
- bckr 2y agoSurely we’ve learned some things? After Mythical Man Month there’s been other books (and talks), yes? I’ve read The Phoenix Project (based on The Goal) and its sequels. What should be on every EM’s shelf?
- skydhash 2y agoPeopleware by Tom Dermaco & Timothy Lister. Making Things Happen by Scott Berkun. Bu I haven’t finished reading it yet.
- eru 2y ago> Surely we’ve learned some things? I was exaggerating a bit. Brooks lamented that we've learned so little, that his observations stay relevant, instead of being superseded by something more systematic. In contrast, if you were learning how to write a compiler or operating system today, you (hopefully!) wouldn't pick up a book published when the Mythical Man Month came out.
- worldsayshi 2y agoWhen building a plant you can only build the same plant once. When building software you can keep iterating on the same software forever. How do you know when to start over and when to keep going? There seems to be no consensus on that?
- roenxi 2y agoIt is an interesting theory and a nice story; but I don't believe it. One of the key issues in programming systems is the profound uncertainty about what the system is meant to be doing. In chemical engineering you know exactly what is supposed to be built and have a clear idea of how the major reactions should work and what the tolerances are. Both situations require design around uncertainty, but the chemical engineer is looking for practical kinks in a roughly-understood system. The programmatic system has no idea what is value add, what will stay or go or anything like that. In the extreme case you get things like Slack or Discord, where the plan wasn't even trying to build communications software to start with. The nature and scale of the uncertainty is different. Software needs to adopt a fail-fast iterative approach with lots of feedback. Chemical engineers are looking for something else. The "pilot plant" concept wouldn't carry to software. Although the "we're going to throw this out" attitude works wonders (unless you rely on it happening, in which case that code is permanent now for some reason).
- deleted 2y ago[deleted]