We do "one-pagers" if there's basically one, simple, straight forward way to do something; however, I'm with google on this one.
If you're designing something, and there's only a single solution under consideration, either there's no design, or you're not being thorough. Choices and tradeoffs are what make design
What if it is something really obvious and has been done so for last 20/20 times it feels almost embarrassing to consider anything else? You could list out the embarrassing methods, but it still feels useless work for show.
I don't want to get sucked into defending Google-style design docs (I have.. opinions), but on this particular point a couple of things come to mind:
1. Presumably you've written the doc to be read by other people. What's obvious to you might not be obvious to them.
2. If you have no "alternatives considered", it's an indicator that you didn't consider any alternatives. I can think of times when "this is obvious and it's the way we've always done it" sent me down the wrong path. Spending just a couple of minutes considering whether obvious == correct, and writing down why, is not a bad investment in the long term.
3. I can only speak for myself, but I don't enjoy being criticized and I don't enjoy being wrong. "Alternatives Considered" is often at the end of the doc and I'm tempted to avoid it because there's a very real possibility that I will find the process of explaining why we don't just do option B instead leads to a realization that option B is a better alternative than the plan I just spent all that time on.
9/10 times it's short and easy, but it's still a worthwhile exercise for the reasons above. Explaining the "don't do anything" alternative is a good way to reinforce the cost/benefit of what you're proposing, and it's usually pretty easy to put yourself in someone else's shoes for a second and think of the first "but why don't you just" that will probably pop into their head. Write down "because it won't scale" and you've saved yourself that conversation. (joking. maybe.)
> I can only speak for myself, but I don't enjoy being criticized and I don't enjoy being wrong.
That's actually a huge problem because it can veer onto intellectual dishonesty and being combative for nothing.
Instead, one should be trying to look for the right/best path forward, regardless of what they thought.
Should be easy to discard erroneous ideas.
The goal is not to be right. It's to find what's right.
I had a wise friend tell me that engineers are always in a state of being wrong. What you build today you will most likely laugh at in five years. The goal for today is to build the least wrong thing you can.
I used to argue more than I should have simply because I didn't like being wrong either. After hearing this, it helped me to become more objective.
My problem is that the least wrong thing I know of is very different from all existing processes, and take more time and money than most are willing to stomach.
Indeed, but then there is, "using a query language designed for data analysis in event sourced systems to: read, parse, version, and write system and configuration files instead of using VCS like Git" levels of wrong, and sales/marketing professionals in charge of the system wrong.
Time is measured in quarters, money is measured vaguely by proximity to sales.
Thought using excel as a database was bad? Try working in a system where strings are `eval`ed in SQL, and every state change is stored in intermediate or virtual tables, then thrown away, so no actual version control is taking place; just diffing and merging Unix configuration files.
Why not use diff and patch? Takes too much time and money, they only know SQL.
>The goal is not to be right. It's to find what's right.
This is why I think design docs need to be lightweight and reviewed early. Design docs shouldn't be a masterpiece perfected in isolation over the course of days or weeks. That guarantees the author has calcified their opinions. When I was on review panels at Amazon, 99% of them were an exercise in futility -- the author had already poured concrete. It is very, very, very hard to avoid the mental trap of "Hrmph! I've thought about this more deeply than anyone else" that comes from living down in the isolated world of "doing design."
The earlier you get other eyes involved, the more likely people will actually listen to feedback and consider alternatives. You still, of course, need that heads down time to put in all the details, but the overall shape of the design shouldn't be a big reveal when you hit the design review.
I think there is a risk of going too far in the other direction leading to design by committee. It’s often the case IME that a casual reader actually hasn’t thought through the problem enough to understand why their drive by feedback or alternative doesn’t make sense. A process that results in those things getting accepted may just be introducing more entropy into the design process.
Good comment. I think both of your perspectives are fair and manifest in the size of what is being designed.
Meaning that if someone designs something huge, end-to-end, it's going to be difficult for external people to address potential flaws within the design.
A lot of interlinked parts requiring to have the full mental model loaded in the brain.
So one should go step by step.
It's also true that not every feedback is equal and it's important to think in advance about how to address rebuttals since most people don't give in-depth feedbacks but surface gut feeling (which can be invaluable too, even if simply in terms of UX), unless they have wondered about how to solve the same exact problem before.
That requires more time spent thinking about the design.
So much this. Bouncing early design ideas (informally) off other stakeholders or at least more experienced engineers can save SO much pain. The reverse of that is true, too: giving early feedback on other people's designs can give them the insights THEY need not to inflict pain on YOU.
You don't get promo in your scenario either. A design doc for something that's trivial will be called out in promo packet review and not given much credence. If the packet is primarily comprised of such artifacts the promo will be denied.
It depends on level. For a junior, these are great design docs because they educate other juniors about engineering, and educate senior bad-doccers about good doc writing, and show developing skill in the art of doc writing, before the engineer has the additional cognitive burden of writing about something much harder.
Hmm...most of the time when I do a design that's for something at all substantial, I'll usually go through a few ideas that seem reasonable at least through the "napkin stage" before dumping them in favor of what eventually becomes the "real design". I'd just save those napkins, list them in the alternatives section, and explain why they were abandoned. Easy.
If you're designing something, and there's only a single solution under consideration, either there's no design, or you're not being thorough. Choices and tradeoffs are what make design