Do something, so we can change it
allenpike.com
allenpike.com
Instead, I have found that decisions work by "path dependency". If something works, even if it is a poor implementation, the path to get there is holy ground and the amount of effort to change a 10 minute decision that was made flippintly by two business people chatting in the urinals on a Wednesday is like trying to siege the walls of Jehrico.
There's no solving this problem because it is fundamentally human in nature. The egos are invested in the existing thing -- so improving the proof-of-concept-that-is-now-hastily-shoved-into-production problem requires that you unravel every person's thoughts and pride on the current thing, regardless of the seriousness of the problem. And so the problem cannot get solved and change cannot happen unless something catastrophic occurs.
Thus, the line-worker software engineer, who has no real organizational power, has to hope that the proverbial printer falls down a flight of stairs "accidentally" so that they can swap out the black ink cartridge to a new one that doesn't make weird bleed lines on the edge of every page. That way, when the new printer comes in, and someone complains that the ink bleed is gone and how they liked that, that you can feign ignorance.
If the team/org is too high-ego to actually treat 2-way decisions as 2-way decisions after they get made, I think that's a bit of a different problem. The org has to invest in the "so we can change it" part of the plan.
There’s gotta be a balance between waterfall and fake agile, but I haven’t found it yet.
Which kind of begs the question: "if a piece of software is not actively and visibly misbehaving, why does it need refactoring?"
A number of reversible decisions over the course of the years resulted in a terrible architecture.
Something is broken but nobody knows exactly what it is and there’s no organizational will to get it fixed.
- "Nothing bad happens" might be the accumulation of risk until something _very_ bad happens.
- Something bad might actually be already happening, only silently. For example, teams suffering unnecessary difficulty whenever they need to work on some part of the codebase, but it's considered "normal" because that's life now.
The version that I’ve always experienced in practice is “we spent six months fixing bugs and it’s still broken, because we did not read the first page of the docs. No we do not want to read the docs now. Look I found a stack overflow post where some unknown, unqualified fool who is also incapable of reading the docs says to do it this way”.
Weeks of bug fixing can save you literally hours of planning.
The flip side is often to ask the people doing the work for input, there's a good chance they know what's best. There's often a group that can make decisions and implement the decisions, and another group that can only make decisions, and so naturally we divide the work so that those who cannot implement the decisions make the decisions and those who can do both don't ever get to make decisions.
A common pattern I've seen is a team or organization getting in the habit of collecting little papercuts where no individual problem is bad enough to register but, over time, the codebase becomes slow and painful to work on. What's especially dangerous is that the state of the system informs people's expectations: what's easy, what's hard, what's possible at all. You get to the point where changes that should be easy are seen as inherently difficult and people start making strategic decisions that implicitly compensate for this, masking the accumulated problems even further.
It's a 20 year old codebase, so it's gotten so bad that we spend 2 weeks planning something that could take me 1 week to write in the current codebase or 1 day to write in a sane codebase, on a product that I could probably re-write from scratch in a month.
Should good decisions sometimes be reversed? Of course! They were a good decision based on information available at the time.
i.e. the classic line "It's Easier to Ask Forgiveness Than It Is To Get Permission" ...Rear Admiral Grace Hopper
[0] https://quoteinvestigator.com/2018/06/19/forgive
[1] https://spectrum.ieee.org/did-you-know-edison-coined-the-ter...
Even the freeest "two-way door" decision becomes one-way over time because every day is a step farther away from that door, and another step you have to backtrack in order to go back through it.
> This is a best effort hack based on X and Y. It might not be 100% correct. Feel free to improve it.
> - Name, 2023-08-05
But dangit, sometimes you need to trust that you have a better solution and just execute! But it's not that easy.
the solution is unity. you are right that with a someone in a position in power making decisions it can be very difficult to change that, but when the whole team makes a decision then the whole team can also change that decision.
what is important here is to develop that mindset that everyones input to a decision is valuable. the challenge is that this requires trust that needs to be developed
That is one thing that can happen, because it is part of human nature. But it is not the whole of human nature. if you have a culture of experimentation and two-way doors, people learn to invest not in one particular experiment, but the process of experimentation. They invest their egos not in one particular outcome, but in the team and their long-term success.
I get that the dominant culture in American business is managerialism [1], where we all have to pretend that people currently holding power are brilliant, while they have pissing contests over their place in the corporate dominance hierarchy. But that's not the only way things can possibly work. I've lived different approaches, as has the author of the piece.
[1] https://www.amazon.com/Confronting-Managerialism-Business-Ec...
To call hierarchical authority "human nature" is to ignore not only theoretical viability, but also demonstrated present-day viability as well as modern anthropological and archaeological understandings of realities explored in our pasts.
Sadly most of us have bosses or subject others to it, and we bind ourselves to these structures by legal contract and risk being identified as insubordinate if we try to do better.
Sociocratisch Centrum co-founder Reijmer has summarized the difference as follows: "By consensus, I must convince you that I'm right; by consent, you ask whether you can live with the decision".
Maybe. It can be as simple as loss aversion.
This demonstrates why bringing in an outsider to make sudden rapid changes, and renaming/rebranding are both ways that can cut the Gordian knot.
IMO only now is Amazon starting to run into the long term consequences of massive adhoc inhouse tech tools, probably only worsened by defensive coding techniques to combat stack rank evals.
I'd like to say that the most modern example of two way door decisions is hiring someone, because you can always just fire them immediately as the stack rank sacrificial lamb. See? Easily undone.
None of us like to admit we were wrong, the more power / responsibility we hold the harder it gets. A lot of people feel insecure deep down because their position in the org was gained roughly by accident and they can’t reliably reproduce their success in another place, so their ego / reputation becomes an incredibly touch subject.
We as devs have an incredible luxury of being able to pack up our stuff and deliver a working solution in another team / company / country / continent reliably. A lot of business people either don’t have that, or believe they don’t, same thing really.
So the way to approach it becomes understanding how vulnerable people in power feel, helping them out and building alliances that way, and when they start trusting you, then you can bring to bare even outlandish proposals and be supported.
Sadly we are all still primates, building the most elaborate tree ever, and one has to take that into account.
This reminds me of a game design technique Blizzard learned to use back in the day when balancing their RTS games. Sometimes they'd make a small change – say increasing damage by 4% – and playtest the result. It seemed, maybe better? So they'd ship it. Some time later, they'd realize they had way undershot, and the ideal increase would have been 25%. They sometimes found themselves buffing or nerfing the same thing over and over, trying to get it right.
The approach that worked better for them was to err on the side of first overcorrecting – say, try increasing damage by 40%. This way, in playtesting they could clearly see the effects of having gone too far, then back off the change as appropriate.
One of my big rules has always been, "double it, or cut it in half". Don't waste your time adjusting something by 5 percent, then another 5 percent, then another.. just double it, and see if it even had the effect you thought it was going to have at all.
This is what musicians do - put in nonsensical filler lyrics until they work out the rest of the song. Sometimes the throwaway lyrics are even kept. The Beatles did this to great effect in the Get Back documentary. It was so cool to see how the now legendary songs took shape. You got to start somewhere. Everything is iterative.
When I read "I'll admit I only skimmed this article" I though maybe due to blocked JavaScripts the article didn't load for me and I only read the preface of the actual article or something...
This was not an argument in favor of not writing design docs, but instead an argument in favor of moving towards prototype while waiting for people to weigh in on a design instead of doing nothing with that downtime.
A terribly common error is having a debate over how something should be designed, and then never resolving the debate. Brian Valentine, the lead developer on Windows 2000, was famous for his motto “Decisions in 10 minutes or less, or the next one is free.”
[1]:https://www.joelonsoftware.com/2000/10/02/painless-functiona...
The products work for people, but nobody loves the products, they tolerate them.
Win 7 was stable and user-friendly, as was Win2k years earlier -- but for some reason, MSFT directed consumers to ME and Vista, which were garbage.
On top of all that, people in specialized roles tend to invent jargon, then use it as an excuse to treat others as inferior or outsiders instead of putting their ideas to the test by explaining them to the rest of the world. People who do that tend to be interested in maintaining an upper-hand status-wise rather than actually getting shit done.
In most cases, you already have 99.9% of the common language, including an acceptable common metalanguage embedded into it. Coming up with mutually understandable definitions is a bit of work, but it's far from unsurmountable.
Note how many legal papers and even scientific papers start with definitios. Other technical communication should, too.
He's also the person who once approved some request for money and complained that it was a waste of his time to ask for so little. I agreed, but, corporate policy.
I’ve had many potentials partners be stuck in the “we support what you’re doing, let’s talk, and keep talking” phase
and when I put them in the slide deck or team page that’s how I learn who is really with me
everything from
“use this picture instead, let’s rock!”
to
“Omg my firm can’t be involved in this!”
Its much faster of a resolution than waiting for an undetermined ambiguous level of comfort that may never come
I was talking with a first-time co-founder recently, and had to break the news to them that many people in startup space will always say they're interested, and never say no.
I've guessed it's to keep their options open, and to avoid/delay negative associations with the speaker that would come from saying no. (I suppose some might also do it for selfless reasons, of not wanting to discourage someone.)
> and when I put them in the slide deck or team page that’s how I learn who is really with me
I like that general idea, for cutting through some of the noise. I'll have to think about how to adapt it to my style.
Related, but maybe distinct...
I don't know how common it is among choreographers, but a methodological tool of at least one modern dance choreographer, working on a new piece, is to have a session with the dancers, and have them individually improvise a particular part, under some direction. Then she'll do things like, "Oo, everyone try what Jane is doing."
Great wording. I'll pick a forgotten reference, from not really that long ago. Anyone remember the Kin[0]?
[0] https://www.engadget.com/2010-07-02-life-and-death-of-micros...
1 is the easiest.
2 should keep you out of "failing fast" with irreversible decisions or ones that have consequences of causing permanent damage or giving up your freedom or power.
3 are you coacheable enough to embrace the required level of mindset change? will you develop mastery for the next iteration at the required speed?
4 collecting quality feedback is not always trivial or cheap.
5 this is the hardest to get, are you surrounded/listening to true friends (celebrators of your success) or fake ones (envy in disguise poisonig misleading advice so they don't feel outshined by your success)?
Author explicitly said he was talking about Amazon, but I don't think he was talking about Amazon.
> Maybe you put some conditions on your $44 billion acquisition offer, and – if the deal goes through – maybe you refrain from repeatedly permanently sabotaging it, like some kind of ridiculous gibbon. You know, that kind of thing.
But that eternal changing .. difficult to accept..
btw. there's a related pattern in the Organisational patterns of Agile book [1] - "Someone always makes progress"..
[1] Organizational Patterns of Agile Software Development - James Coplien, Neil Harrison
Well... it is true that not everyone believes that knowing what they want, and reaching out to those who need to know it in order to perform, is a necessity for success in the world of television... and this is the part where they come out from their slimy, shit-stained hole and excuse their lack of vision (or their unwillingness to impart that vision) with a defense I consider to be the most cowardly and thieving seven words in the showrunner's lexicon:
"I'll know it when I see it."
If you ever find yourself saying that, kindly consider the possibility that - and I mean this, from the heart - your impostor syndrome is most likely real and you are, in fact, a shrill, shrieking fraud.
Here's what "I'll know it when I see it" means to me and to everyone who hears it from a showrunner: "I have no original ideas of my own but am perfectly willing to let everyone else spin their wheels and exhaust themselves emotionally and creatively so that I can eventually cherry-pick the best of their genius and claim it for my own."
[1] https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_o...