3 ms·

You have successfully optimized for fast, but you have not optimized for quality, extensibility, customer experience, or maintainability. Fast can be a great t

You have successfully optimized for fast, but you have not optimized for quality, extensibility, customer experience, or maintainability. Fast can be a great thing to optimize for, but there are many other situations where other optimizations are preferable.

fmbb 19d ago
> you have not optimized for quality, extensibility, customer experience, or maintainability A ”software design” document does not optimize for either of those.
- blanched 19d ago
  Why not? “Customer experience” is arguable, but most design documents I’ve seen involve the others.
- AnimalMuppet 19d ago
  The absence of a software design document can definitely harm quality, extensibility, and maintainability.
phuff 19d ago
Welcome both of you to the agile vs waterfall arguments of 25+ years ago. :) The agilists I think ended up having pretty good answers for finding a sweet spot between small iterations that maintained quality while minimizing Big Design Upfront to prevent spending a lot of time preplanning the software, allowing a well functioning agile team to maintain reasonably high quality, extensibility, maintainability and satisfaction of actual customer needs while keeping velocity high and not getting bogged down in design heavy tar pits which were ended up not fully anticipating problems encountered during actual execution. If that doesn't sound like a buzzword filled sentence I never expected to come out my mouth... But. The bottom line is: if you can keep your execution goals small and focused enough, you can iterate quickly towards a design with better information than you would have if you were to do a design study because you'll be better informed by the actual needs of the execution process than by what you _think_ the execution process will require at design time.
- gfody 19d ago
  25 years ago the agile manifesto taught us to go extreme by taking our well written, sea-level consistent use case documents and shredding them into user stories, that can fit on stick-its. it's a pretty good idea assuming you actually had something to shred - but then we started writing user stories instead, sea-level depending on who wrote it, functional cats mixing with non-functional dogs, under water and then raining frogs.. soon said the devs: we don't need no stinkin' docs

fmbb 19d ago

> you have not optimized for quality, extensibility, customer experience, or maintainability A ”software design” document does not optimize for either of those.

blanched 19d ago
Why not? “Customer experience” is arguable, but most design documents I’ve seen involve the others.
AnimalMuppet 19d ago
The absence of a software design document can definitely harm quality, extensibility, and maintainability.

phuff 19d ago

Welcome both of you to the agile vs waterfall arguments of 25+ years ago. :) The agilists I think ended up having pretty good answers for finding a sweet spot between small iterations that maintained quality while minimizing Big Design Upfront to prevent spending a lot of time preplanning the software, allowing a well functioning agile team to maintain reasonably high quality, extensibility, maintainability and satisfaction of actual customer needs while keeping velocity high and not getting bogged down in design heavy tar pits which were ended up not fully anticipating problems encountered during actual execution. If that doesn't sound like a buzzword filled sentence I never expected to come out my mouth... But. The bottom line is: if you can keep your execution goals small and focused enough, you can iterate quickly towards a design with better information than you would have if you were to do a design study because you'll be better informed by the actual needs of the execution process than by what you _think_ the execution process will require at design time.

gfody 19d ago
25 years ago the agile manifesto taught us to go extreme by taking our well written, sea-level consistent use case documents and shredding them into user stories, that can fit on stick-its. it's a pretty good idea assuming you actually had something to shred - but then we started writing user stories instead, sea-level depending on who wrote it, functional cats mixing with non-functional dogs, under water and then raining frogs.. soon said the devs: we don't need no stinkin' docs