Abby is awesome and an old friend from NYC ux & information architecture scene in early 2010s.
Her book is great, and like others mention, the homepage is just the TOC. Go buy it!
Ultimately, the mess is yours to make it helpful for stakeholders.
In almost 20 years of working in FinTech at various banks, hedge funds startup etc, a lot of this rings true.
e.g.
- Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used and 90% of the time they are used it's b/c I made one
- SO many important processes are not documented so people can't even opine about how to fix them. I once documented a process and everyone agreed step 4 was wrong. What was amazing is no one agreed on what step 4 actually was.
- Most of the big arguments I've seen about projects are less "what should we do" but more "when do we want it" e.g. one party want's it next week but another one wants to have more features so it will take longer. [1] I've often dealt with this by using the following metaphor:
"Oh, so you want to move house every two weeks?
If you give me six months I'll build you the world's most amazing Winnebago/RV with a hot tub, satellite TV, queen size bed and A/C.
If you want it tomorrow I'm going to give you a wheelbarrow, pillow and an iPad."
I've observed that messes and complexity often but not always tends to just be noisy information streams. If you try to make a decision based on large volumes of low quality data, the world feels incredibly complex and constantly shifting and self-contradictory.
If you manage to improve the signal to noise ratio it feels a lot more manageable and understandable.
Worked with an enterprise architect once who couldn't say anything that didn't start with "in this complex and ever changing information landscape". You built this complex and ever changing information landscape, sir. It consists of your hexagonal architecture, your microservices, your kubernetes cluster.
My experience is that one mess is pretty straightforward, what is debilitating is interconnected messes.
System A is the highest priority fix and we want to incorporate parts of system B into system A (they never should have been in B) but if we move them to system A, the other parts of system B will break (so we need to fix those) and then additionally system C will no longer work so we need to fix that, and on and on…
I was a bit confused by this until I realized that this is just a table of contents and the sentences in each chapter are links. They are not obviously styled like hyperlinks.
One trick that I always fall back on is to make a dependency graph. In meetings I used to pull up yuml.com but now I use mermaid. You can just start typing text and arrows and it renders in real time what depends on what. It's great in a live meeting to help focus people on where the problem really is, or in documentation to show why a change here will affect something there.
Both yuml and mermaid don't get you control over layout. I think that's a feature. If the layout engine can make a pretty picture that means your dependencies aren't too complex, but if the graph looks terrible and complicated, that means you're system is also probably terrible and complicated.
I wish we could use that. I can’t use them because mermaid doesn’t have a way to assure no data is stored on mermaid servers so I can’t use it for anything proprietary or even work related at all. LucidChart has a way to tie into Corporate though
- Situation: The pilot is required to recognize the current situation and identify the possible dangers. This is the most important step of the decision-making process since detecting the situation accurately gives the critical information to start the process correctly and produce a feasible resolution to the impending situation.
- Options: Generate any possible option regardless of the feasibility of success. It is most important to create as many options as possible since there will be a larger pool of options to choose the most appropriate solution to the situation.
- Choose: From the options generated, the pilot is required to choose a course of action assessing the risks and viability.
Act: Act upon the plan while flying in accordance with safety and time availability. The most important step of this process is time, as the pilot is challenged against time to fix the problem before the situation further deteriorates.
- Evaluate: Ask the question, "Has the selected action been successful?" and evaluate your plan to prepare for future occurrences.
You can't talk about messes without talking about Garbage.
When a mess is inevitable, maybe even on purpose. Landfills, toxic waste dumps; every organization has them, needs them.
I once worked in a department that was a dumping ground for failed projects. A 10 year long mess; it was both constant garbage and an essential scapegoat. A mess that everyone can blame, from the C-suite, to peer organizations, to even the people who worked inside the org.
All: "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
It's not that these things aren't annoying—it's that they are annoying, and that drives tons of dyspeptic, offtopic discussion that in the end drowns out anything that's actually interesting. Since that's a bad outcome, we need to refrain from driving the thread there.
Sorry dang, but I have to disagree. Nothing about this site design is "too common to be interesting." The whole thing is highly irregular. In an extreme case like this, the weirdness of the layout has to be considered a *principle feature* of the website, not a side distraction. Another commenter mentioned Time Cube, and that's not far off.
Commenters are correct that the whole thing reads like a meta joke, where the site itself is a mess. We have to at least consider the possibility that the author is in on the joke.
Petition to eliminate this stub, and merge this discussion of *the website's primary distinguishing feature* into the main conversation.
Just wanna express my thanks to all the complaining comments here, they helped me set expectations so that I wasn't too disappointed when the site actually did turn out to be an unreadable hot mess.
All: "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting." - https://news.ycombinator.com/newsguidelines.html.
It's not that these things aren't annoying—it's that they are annoying, and that drives tons of dyspeptic discussion that in the end drowns out anything that's actually interesting. Since that's a bad outcome, we need to refrain from driving the thread there. (I've moved these complaints to a stubthread: https://news.ycombinator.com/item?id=45389100 - if anyone has an urge to reply, it would be fine to do so there)
(p.s. what look like chapter headings in the OP are in fact hyperlinks)
Interesting to see it crop up here. I met Ms. Covert when she released the book and have a signed copy around here somewhere. It remains relevant as ever, and has value well beyond UX practices. It’s a short read too, I recommend it.
totally agree with what dang posted here; obvious nitpicks aren’t worth discussing. it’s refreshing to see that principle on HN.
I also want to add another thought to that: I’m so glad howtomakesenseofanymess.com exists, warts and all. I’d much rather it exist in some imperfect form than not exist at all.
We ought to be more accepting of good and imperfect creations, because that encourages creativity. We need more of this!
21 comments
[ 0.18 ms ] story [ 41.0 ms ] threade.g.
- Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used and 90% of the time they are used it's b/c I made one
- SO many important processes are not documented so people can't even opine about how to fix them. I once documented a process and everyone agreed step 4 was wrong. What was amazing is no one agreed on what step 4 actually was.
- Most of the big arguments I've seen about projects are less "what should we do" but more "when do we want it" e.g. one party want's it next week but another one wants to have more features so it will take longer. [1] I've often dealt with this by using the following metaphor:
"Oh, so you want to move house every two weeks?
If you give me six months I'll build you the world's most amazing Winnebago/RV with a hot tub, satellite TV, queen size bed and A/C.
If you want it tomorrow I'm going to give you a wheelbarrow, pillow and an iPad."
0 - https://www.howtomakesenseofanymess.com/chapter3/67/2-flow-d... and https://www.howtomakesenseofanymess.com/chapter3/71/6-swim-l...
1- https://www.howtomakesenseofanymess.com/chapter3/51/reality-...
And this usually ends bad. Yet it keeps repeating because there are no lessons learned (but learnings /s).
The powers that be keep calling everything a success until the next reshuffle.
Then it all repeats all over again (I'm clearly jaded by my recent experiences).
If you manage to improve the signal to noise ratio it feels a lot more manageable and understandable.
Worked with an enterprise architect once who couldn't say anything that didn't start with "in this complex and ever changing information landscape". You built this complex and ever changing information landscape, sir. It consists of your hexagonal architecture, your microservices, your kubernetes cluster.
System A is the highest priority fix and we want to incorporate parts of system B into system A (they never should have been in B) but if we move them to system A, the other parts of system B will break (so we need to fix those) and then additionally system C will no longer work so we need to fix that, and on and on…
Both yuml and mermaid don't get you control over layout. I think that's a feature. If the layout engine can make a pretty picture that means your dependencies aren't too complex, but if the graph looks terrible and complicated, that means you're system is also probably terrible and complicated.
- Situation: The pilot is required to recognize the current situation and identify the possible dangers. This is the most important step of the decision-making process since detecting the situation accurately gives the critical information to start the process correctly and produce a feasible resolution to the impending situation.
- Options: Generate any possible option regardless of the feasibility of success. It is most important to create as many options as possible since there will be a larger pool of options to choose the most appropriate solution to the situation.
- Choose: From the options generated, the pilot is required to choose a course of action assessing the risks and viability. Act: Act upon the plan while flying in accordance with safety and time availability. The most important step of this process is time, as the pilot is challenged against time to fix the problem before the situation further deteriorates.
- Evaluate: Ask the question, "Has the selected action been successful?" and evaluate your plan to prepare for future occurrences.
https://en.wikipedia.org/wiki/Pilot_decision_making#Decision...
---
Working on a legacy codebase last year I kept repeating to myself: They made it work, they didn't make it sensible.
I once worked in a department that was a dumping ground for failed projects. A 10 year long mess; it was both constant garbage and an essential scapegoat. A mess that everyone can blame, from the C-suite, to peer organizations, to even the people who worked inside the org.
Wikipedia has a great primer on the topic, which I think is more incisive than the OP's holistic framework https://en.wikipedia.org/wiki/Garbage_can_model
All: "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
It's not that these things aren't annoying—it's that they are annoying, and that drives tons of dyspeptic, offtopic discussion that in the end drowns out anything that's actually interesting. Since that's a bad outcome, we need to refrain from driving the thread there.
https://news.ycombinator.com/newsguidelines.html
Commenters are correct that the whole thing reads like a meta joke, where the site itself is a mess. We have to at least consider the possibility that the author is in on the joke.
Petition to eliminate this stub, and merge this discussion of *the website's primary distinguishing feature* into the main conversation.
It's not that these things aren't annoying—it's that they are annoying, and that drives tons of dyspeptic discussion that in the end drowns out anything that's actually interesting. Since that's a bad outcome, we need to refrain from driving the thread there. (I've moved these complaints to a stubthread: https://news.ycombinator.com/item?id=45389100 - if anyone has an urge to reply, it would be fine to do so there)
(p.s. what look like chapter headings in the OP are in fact hyperlinks)
I also want to add another thought to that: I’m so glad howtomakesenseofanymess.com exists, warts and all. I’d much rather it exist in some imperfect form than not exist at all.
We ought to be more accepting of good and imperfect creations, because that encourages creativity. We need more of this!