10 ms·

UI is a function of your organization

173 points by damethos 3y ago

gjvc 3y ago
see also https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law and the fact that the same tropes are recapitulated over and over again without any reference to prior art. Alan Kay is correct; computing is a pop culture.
- reubenmorais 3y ago
  Reminds me of the Free Energy principle a bit: https://en.wikipedia.org/wiki/Free_energy_principle https://en.wikipedia.org/wiki/Free_energy_principle
deleted 3y ago
[deleted]
andsoitis 3y ago
Conway’s Law from 1967. [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent?
- junon 3y ago
  I've never really agreed with this assertion. What gives it the weight of being an axiom?
  - pavlov 3y ago
    Communication flows create dependency points that limit what the design can be. Consider an organization that designs broom handles. They have an industrial design department that selects the shape and material, and a market research department that selects the color and packaging to fit current trends. If the market research is purely downstream from the industrial design, their feedback can never affect the tactile properties of the product, thus limiting the range of possible designs. Replace the physical product with an abstract system, and the same design dependency issues apply.
  - btbuildem 3y ago
    I would say it's very hard if not impossible to find a counterexample.
    - zeroonetwothree 3y ago
      I have certainly worked on software that didn’t follow it (ownership of one thing was spread out across different teams). But it was certainly a huge pain to get anything done. So I think the reasons we typically follow Conways law are good
  - munificent 3y ago
    Conway's basic argument is pretty simple: 1. For any two software systems to interact, they must use some sort of agreed API or protocol. 2. In order to have that agreed API or protocol, the teams building those two systems must communicate in some way (even if it's just one-way communation where one team documents an API and the other consumes it). 3. Therefore, the communication structures of the software system will reflect the communication structures of the organization. So the software architecture mirrors the org chart.
lylejantzi3rd 3y ago
The Only Unbreakable Law - Conway's Law. https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY
tobr 3y ago
Is this a response to UI = f(statesⁿ)[1] or are they both a response to something else? 1: https://daverupert.com/2024/02/ui-states/ https://daverupert.com/2024/02/ui-states/
alias_neo 3y ago
So who's going to tell us that the Domino's Pizza Tracker is just a timer? I don't eat there often, but when I have, the Pizza sits in QA for about 10 minutes, then is "out for delivery for about 15, despite the fact I could literally walk to the place in 15 minutes, and they sure as heck and walking my pizza to me. Then there's the fact that they outright lie by saying it has been delivered, then turning up about 10 minutes later. Between the fact it's not the best pizza and this dodgy behaviour, they pretty much make sure I don't eat from there more often than about quarterly.
- xnorswap 3y ago
  It's a failure of incentives for accurate tracking. It's the same reason that when you buy from McDonald's, the order shows on the screen as "ready for collection" then "collected", then disappears from the screen well before the food has hit the counter at all. The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality. Domino's are particularly bad (or noticeably bad) for it. It's an important lesson about remote top down control and a failure mode of JIT systems. I've long wanted to prepare a proper blog post about this exact phenomenon using Domino's and McDonald's as examples, but I haven't put in the effort to collect the right evidence to fully understand the negative effects of IT systems misrepresenting reality.
  - shaan7 3y ago
    Yup. I pickup my orders from Domino's quite regularly and it the tracker is reliable. The only thing that does happen is that they sometimes do mark it "Ready for pickup" while someone still needs to take the pizza from the oven and put it into a box. So I sometimes wait a minute seconds at the counter for that to happen.
  - madeofpalk 3y ago
    If you've ever been told to wait in the parking lot at a fast food drive through, it's because the store has a metric on dwell time and throughput that they're optimising for.
exabrial 3y ago
I used to think Apple was the king of UIs. They have long departed from quality and functionality; Jobs has a no nonsense approach where form followed functionality. If it functioned properly, the form was intuitive. Apple UI interfaces from the Jobs years were incredible. Nowadays, under forced yearly redesign policy, we’re reversed so far things are just hidden and awkward. Kinda funny: you force it and it sucks.
- andsoitis 3y ago
  > I used to think Apple was the king of UIs. The way I see it is that Apple excels at designing and building UI patterns and systems (I don't think anyone comes close), but they're terrible when it comes to the UI of actual software products.
  - velcrovan 3y ago
    For UI patterns and systems, do you have a post-Jobs example? I'm thinking the word in that last sentence should be “excelled” (past tense).
    - agloe_dreams 3y ago
      I have one - The iPhone X's swipe navigation is brilliant. There is a little WebOS in there in multitasking gestures left and right, but it is such a straightforward system that works.
      - velcrovan 3y ago
        When we say “UI patterns or systems” we mean frameworks that provide high-quality defaults for all the software written for that system. Card/swipe navigation is a specific affordance of iOS — like Alt+Tab switching on desktop OSs — not a pattern or system. Further, as you mention, it was invented by Palm and copied by Apple eight years later.
- donatj 3y ago
  See: System Settings System Preferences I could pretty intuitively find anything I was looking for. The newer System Settings is basically unusable outside of search
socialentp 3y ago
Steven Sinofsky wrote about this in the context of the early days of Microsoft in “Don’t ship the org chart” https://hardcoresoftware.learningbyshipping.com/p/047-dont-ship-the-org-chart https://hardcoresoftware.learningbyshipping.com/p/047-dont-s...
- hitekker 3y ago
  I'm pretty skeptical of what Sinofsky says. Back in the day, former Microsoft employees called out the differences between what he said and what he did, i.e. "Don't ship the org chart" -> his own org ships the org chart. https://news.ycombinator.com/item?id=4778996 https://news.ycombinator.com/item?id=4778996 https://news.ycombinator.com/item?id=4776031 https://news.ycombinator.com/item?id=4776031
  - canucker2016 3y ago
    One of the hilarious exchanges (pun intended) that happened on Sinofsky's blog concerned MS Exchange. The executive-level view of events is vastly different from the actual events. tl;dr: Stevesi (Technical Assistant to BillG): Mgmt forced Exchange to use NT Directory (followed by glowing description of the NT directory) DonH (Exchange Directory dev lead/ later Active Directory dev lead): No, NT was late, and eventually canceled NT Directory. Exchange wrote and shipped our own Directory and then moved the code to NT to use as the base for Active Directory. Stevesi prevaricating about high-level executive view of the interaction of NT vs Exchange directory. DonH: No, that's wrong. NT provided nothing. Exchange created an email-specific directory. I used that to make Active Directory. Water flowed uphill not downhill. from https://hardcoresoftware.learningbyshipping.com/p/021-expanding-breadth-versus-coherency https://hardcoresoftware.learningbyshipping.com/p/021-expand...: "That proved to be a defining moment because deploying a directory was hugely complex and there was no way EMS could do it twice. In one of the rare times an architectural choice was pushed to a team, using the directory from NT became a requirement for EMS. Many others supported this, including the Server leadership. It was to them as natural as pushing Excel to use Windows—the directory was that core to NT Server—while sharing files and printers was the baseline scenario, it was the directory that brought deep enterprise value to customers. For the better part of the following year or more, EMS would not speak well of using the NT Directory, and conversely the NT team felt that EMS was trying to use the Directory in ways it was not designed to be used. This sounded to me a lot like getting Excel to work on Windows, and it played out exactly that way. Had EMS not used NT Directory, it is likely Directory never would have achieved critical mass as the defining app for the client-server era (and remained the cloud anchor for today’s Office 365). And conversely, had the NT team not met the needs of EMS, then the NT Directory would have likely been sidelined by the rising importance of the email directory in EMS. Forcing this issue, while it might be an exception, only proved the strength of a strategic bet when it is made and executed. Still, it was painful." Comment from DonH Apr 22, 2021, at end of blog entry: "Speaking as the dev lead for the Exchange Directory (1991-1996) and later on Active Directory (1996-2005), there's a lot wrong with this chapter. NT's approach to functional directory services in the early 90's was "wait for Cairo. they're building one", which meant that we in Exchange had to build our own directory service. When Cairo collapsed (late 1995) Exchange and NT struck a deal so that once Exchange 4.0 shipped (April 1996) one of my developers and I brought a copy of the Exchange Directory source code over to Windows, and we built Active Directory out of that. Exchange in no way "bet on" the NT Directory; we essentially built the replacement for it in order to get the features we needed. Ask me if you need details. However, the part about endless repeated pressure to build everything (specifically including the directory) on top of SQL is entirely accurate. I'm only moderately annoyed that I had to pay ten bucks to post this correction." Second comment from DonH: "You're missing the point that there was no NT Directory. The strategy given to us was "use the NT directory, which is the Cairo directory. Sorry that doesn't exist yet, so Exchange might need to cobble something together for its first release." I built that something, and later went on to use it to fill the directory service shaped hole in Windows. Presenting this as Exchange leveraging the NT Directory might be polite, but it is definitely not accurate. And although I remain eternally grateful to LDAP for saving me from COM I completely agree about omitting it from the history."
ivan_gammel 3y ago
Many people refer to Conway's law here, but I'd argue that this law is true only for the static organization design, where structure is rigid and never changes. This law and and the title of the link hide much more important dependency: organization is a function of business requirements. System design is a function of them too. It MAY happen that organization is designed first, but it is not necessarily the case. Organization changes happen all the time and systems tend to stay during those changes. Many companies have subdivisions organized around the customer journey or certain product topics, e.g. Acquisition tribe or B2B business unit. Those structures work very well and do not reflect the Conway's law (system architecture required in this case is often org-wide and modular, requiring all org units to follow the same design approach).
- btbuildem 3y ago
  It's interesting to think of this in conjunction with the Peter Principle. In any org that's existed long enough, you will have a "crust" of people who have been promoted until they're too incompetent for their position. If long enough time elapses, these incumbents will account for most of the decision makers in the org chart, from the root on down. Given how incentives and motivations change with seniority, it's not a far stretch to assume that they will want to remain where they are - cannot be promoted any further, and would rather not lose current status. I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.
- MajimasEyepatch 3y ago
  Conway's law would still apply in a company where the org chart is changing. Obviously old systems don't disappear in a reorg, but new ones will reflect the communication structures at the time that they were built. In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously. In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.
alberth 3y ago
Domino Pizza tracker The article is centered around the pizza tracker, but I thought that tracker was fake. Just for illustrative purposes. Is it not? https://www.the-sun.com/money/6927297/dominos-pizza-tracker-different-than-expected/amp/ https://www.the-sun.com/money/6927297/dominos-pizza-tracker-...
- Larrikin 3y ago
  I'm sure some MBA douche presented the calculation at headquarters to save the money by making it fake, but when it was first released there was a massive campaign showing Domino's workers getting the orders printed out and hitting buttons at various parts of the process that actually did update the tracker.
  - subroutine 3y ago
    I'm not sure about Dominos, but the last time I ordered Papa Johns, the pizza tracker had a disclaimer that said it was "for entertainment purposes only, and does not reflect actual events"
- diggan 3y ago
  That article is basically "they say, they say" argument between two Twitter users, not sure one could come to any conclusion based on that. It's also a The Sun article, FWIW. I've always thought the tracker was real, at least here in Spain (it looks different than the US one in the article pictures), as it always seems to have changed at different intervals. Could also be just randomized a bit I guess. Long time ago I ordered from Domino anyways.
- 8organicbits 3y ago
  > includes the name of the employee baking each pizza Yikes, I wouldn't put that info online. What's the point?
- gibbitz 3y ago
  My former boss wrote the first version of it when he was working for Crispin-Porter + Bogusky. He claimed that internally Domino's already had the infrastructure for their own telemetry and logistics and putting a python API on top of it to connect to the web was a no-brainer. To hear him tell it, it was his idea. Of course I later worked for a company that was helmed by the former Domino's CEO at that time who claimed it was his idea. Based on the technical backstory I would believe my former boss over the CEO. Of course the existing telemetry at Domino's could be garbage or fake...
shubhamjain 3y ago
The whole post is based on a questionable assumption that Domino Pizza Tracker accurately reflects the status of the Pizza, when it could just be a dumb timer based on a statistical average. Sure, the Pizza Delivery person in the last step has to be accurate, but that's simpler than tracking if the Pizza is in the oven. As for the point itself, I think the real-time status tracking is a very, very small subset of UIs. Yes, it's difficult to deliver if the organization isn't designed around this, but most sucky UIs aren't limited by not having the data.
- rileymat2 3y ago
  Its not perfect, but at Starbucks, the “working on your drink” notification comes when they rip it off the machine, so it is kind of real time. (Kind of, because often they rip off 3 or 4 and stick them to the wall)
- velcrovan 3y ago
  > it could just be a dumb timer based on a statistical average The post makes this point explicitly. It doesn’t sound like you read the whole thing.
  - shubhamjain 3y ago
    My bad! I raced through the article, skipping the important bit.
- deleted 3y ago
  [deleted]
btbuildem 3y ago
Seeing all the mentions of Conway's Law here jogged something in my mind -- could one assert the converse and "reverse engineer" the org structure of a company by examining the systems it has designed? This could be super useful when considering the next place of employment for example; the organizational dysfunctions and idiosyncrasies only become apparent once you've jumped in with both feet.
- 01HNNWZ0MV43FF 3y ago
  Legend has it that Google produces a new chat program every year or two when a high-up manager wants a promotion. Microsoft also seems to have generational UI revamps. There's a funny bathtub curve where Win32 has outlived many of its replacements.
- db48x 3y ago
  Yes, you can! You can even tell when the organization was changed, since many complex systems are upgraded over time. The example I like best is the Windows volume control(s), as pointed out by Casey Muratori (https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY).
deepsun 3y ago
> where the step from “order received” to “pizza in the oven” happens only because of a timer in the UI Then don't lie. Instead of the status, just say outright that it takes up to 5 minutes for the pizza to get in the oven. And show a timer.
hcarvalhoalves 3y ago
Sometimes, UIs are designed with unrealistic expectations and mismatches of how processes work in reality. This is maybe lost on today’s “native digital” generation, but anyone who worked at organizations a while back should understand this intuitively. Back then, processes inside companies where paper-driven, a variation of “produce some kind of document, pass it along to another department, get a stamped copy/receipt to prove it’s been done”. I always use this example when designing architectures and UIs: if you couldn’t design the same process as paper being passed around, the design is missing something. You need to really grok the company structure and the domain to design something sensible.
- couchand 3y ago
  Yes! And, the killer feature of paper that no digital UI has yet to fully capture is the margin. If your business process doesn't have a form field for some data, but the person on the ground understands that it's valuable, it's naturally scribbled onto the margins, and then worked into the next version of the form. If you're using nearly any digital UI, the feedback loop (if it exists at all) is a side channel. More businesses should just use paper.
  - 01HNNWZ0MV43FF 3y ago
    If PDF editing tools were a little better and the average users' file name habits weren't ghoulish we could have digital paper.
    - BeFlatXIII 3y ago
      What naming habits would you like to see the average user adopt?
      - doubled112 3y ago
        If I never see people prepending and appending seemingly random versions again, I'd be thrilled. draft_document.pdf document.pdf final_document.pdf final_final_document.pdf document_final.pdf document_v2.pdf final_final_document_v3.pdf Which one do I use?
kylecordes 3y ago
I have noticed that the Panera Bread status tracker used to provide good information, but doesn't anymore. It frequently says an order is done while it is still being worked on. Might be a UI/Organization mismatch, as described in this article. Or maybe it's the staff intentionally marking things done early, to game metrics expectations from management.
deleted 3y ago
[deleted]
tsylba 3y ago
The Domino's pizza tracking bits is a funny one for those whom had read Snowcrash, where a whole earlier section of the book is about the advancement of the pizza delivery industry. I don't know, it seem to me the 90s had a very dystopian view of future Pizza Hut. « The Deliverator stands tall, your pie in thirty minutes or you can have it free, shoot the driver, take his car, file a class-action suit. The Deliverator has been working this job for six months, a rich and lengthy tenure by his standards, and has never delivered a pizza in more than twenty-one minutes. [..] Pizza delivery is a major industry. A managed industry. People went to CosaNostra Pizza University four years just to learn it. Came in its doors unable to write an English sentence, from Abkhazia, Rwanda, Guanajuato, South Jersey, and came out knowing more about pizza than a Bedouin knows about sand. And they had studied this problem. Graphed the frequency of doorway delivery-time disputes. Wired the early Deliverators to record, then analyze, the debating tactics, the voice-stress histograms, the distinctive grammatical structures employed by white middle-class Type A Burbclave occupants who against all logic had decided that this was the place to take their personal Custerian stand against all that was stale and deadening in their lives: they were going to lie, or delude themselves, about the time of their phone call and get themselves a free pizza; no, they deserved a free pizza along with their life, liberty, and pursuit of whatever, it was fucking inalienable. »
bjnewman85 3y ago
Umm, the argument in the article seems self-defeating. UI=f(org) except we end up with the same UI with radically different orgs because we can just f() over the differences with dark design patterns and users can't tell the difference. I can show you anything in a UI - only good orgs can develop valuable products from those UIs.
vonnik 3y ago
This is a variation of "you ship your org chart." After hearing the outbound version of this truism, I discovered that the inbound version is also true; ie "you buy your org chart." Anyone selling to v large organizations, corporate or government, will know what I mean. Bloated and dysfunctional orgs with eternal sales cycles buy from bloated and dysfunctional orgs that can survive eternal sales cycles, and which are willing to sell bloated and dysfunctional products to satisfy arbitrary criteria. This is one of many reasons why startups have a hard time selling to very large orgs.
cratermoon 3y ago
I order from Domino's now and then. I've noticed that someone named Scott seems to be working preparing pizzas at all hours on all days. It didn't take me very long to figure out that the tracker was just putting in a placeholder event. The actual delivery tracker seems to work OK, though.
deleted 3y ago
[deleted]
jbs789 3y ago
So the output of an organisation is a function of the organisation. Or the amount of effort you put into something affects the outcome. Shocking.
alxmng 3y ago
“To the extent that the business takes place in software, designing the software is designing the business.” @mulegirl from Twitter

173 points by damethos 3y ago

gjvc 3y ago

see also https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law and the fact that the same tropes are recapitulated over and over again without any reference to prior art. Alan Kay is correct; computing is a pop culture.

reubenmorais 3y ago
Reminds me of the Free Energy principle a bit: https://en.wikipedia.org/wiki/Free_energy_principle https://en.wikipedia.org/wiki/Free_energy_principle

deleted 3y ago

[deleted]

andsoitis 3y ago

Conway’s Law from 1967. [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent?

junon 3y ago
I've never really agreed with this assertion. What gives it the weight of being an axiom?
- pavlov 3y ago
  Communication flows create dependency points that limit what the design can be. Consider an organization that designs broom handles. They have an industrial design department that selects the shape and material, and a market research department that selects the color and packaging to fit current trends. If the market research is purely downstream from the industrial design, their feedback can never affect the tactile properties of the product, thus limiting the range of possible designs. Replace the physical product with an abstract system, and the same design dependency issues apply.
- btbuildem 3y ago
  I would say it's very hard if not impossible to find a counterexample.
  - zeroonetwothree 3y ago
    I have certainly worked on software that didn’t follow it (ownership of one thing was spread out across different teams). But it was certainly a huge pain to get anything done. So I think the reasons we typically follow Conways law are good
- munificent 3y ago
  Conway's basic argument is pretty simple: 1. For any two software systems to interact, they must use some sort of agreed API or protocol. 2. In order to have that agreed API or protocol, the teams building those two systems must communicate in some way (even if it's just one-way communation where one team documents an API and the other consumes it). 3. Therefore, the communication structures of the software system will reflect the communication structures of the organization. So the software architecture mirrors the org chart.

lylejantzi3rd 3y ago

The Only Unbreakable Law - Conway's Law. https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY

tobr 3y ago

Is this a response to UI = f(statesⁿ)[1] or are they both a response to something else? 1: https://daverupert.com/2024/02/ui-states/ https://daverupert.com/2024/02/ui-states/

alias_neo 3y ago

So who's going to tell us that the Domino's Pizza Tracker is just a timer? I don't eat there often, but when I have, the Pizza sits in QA for about 10 minutes, then is "out for delivery for about 15, despite the fact I could literally walk to the place in 15 minutes, and they sure as heck and walking my pizza to me. Then there's the fact that they outright lie by saying it has been delivered, then turning up about 10 minutes later. Between the fact it's not the best pizza and this dodgy behaviour, they pretty much make sure I don't eat from there more often than about quarterly.

xnorswap 3y ago
It's a failure of incentives for accurate tracking. It's the same reason that when you buy from McDonald's, the order shows on the screen as "ready for collection" then "collected", then disappears from the screen well before the food has hit the counter at all. The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality. Domino's are particularly bad (or noticeably bad) for it. It's an important lesson about remote top down control and a failure mode of JIT systems. I've long wanted to prepare a proper blog post about this exact phenomenon using Domino's and McDonald's as examples, but I haven't put in the effort to collect the right evidence to fully understand the negative effects of IT systems misrepresenting reality.
- shaan7 3y ago
  Yup. I pickup my orders from Domino's quite regularly and it the tracker is reliable. The only thing that does happen is that they sometimes do mark it "Ready for pickup" while someone still needs to take the pizza from the oven and put it into a box. So I sometimes wait a minute seconds at the counter for that to happen.
- madeofpalk 3y ago
  If you've ever been told to wait in the parking lot at a fast food drive through, it's because the store has a metric on dwell time and throughput that they're optimising for.

exabrial 3y ago

I used to think Apple was the king of UIs. They have long departed from quality and functionality; Jobs has a no nonsense approach where form followed functionality. If it functioned properly, the form was intuitive. Apple UI interfaces from the Jobs years were incredible. Nowadays, under forced yearly redesign policy, we’re reversed so far things are just hidden and awkward. Kinda funny: you force it and it sucks.

andsoitis 3y ago
> I used to think Apple was the king of UIs. The way I see it is that Apple excels at designing and building UI patterns and systems (I don't think anyone comes close), but they're terrible when it comes to the UI of actual software products.
- velcrovan 3y ago
  For UI patterns and systems, do you have a post-Jobs example? I'm thinking the word in that last sentence should be “excelled” (past tense).
  - agloe_dreams 3y ago
    I have one - The iPhone X's swipe navigation is brilliant. There is a little WebOS in there in multitasking gestures left and right, but it is such a straightforward system that works.
    - velcrovan 3y ago
      When we say “UI patterns or systems” we mean frameworks that provide high-quality defaults for all the software written for that system. Card/swipe navigation is a specific affordance of iOS — like Alt+Tab switching on desktop OSs — not a pattern or system. Further, as you mention, it was invented by Palm and copied by Apple eight years later.
donatj 3y ago
See: System Settings System Preferences I could pretty intuitively find anything I was looking for. The newer System Settings is basically unusable outside of search

socialentp 3y ago

Steven Sinofsky wrote about this in the context of the early days of Microsoft in “Don’t ship the org chart” https://hardcoresoftware.learningbyshipping.com/p/047-dont-ship-the-org-chart https://hardcoresoftware.learningbyshipping.com/p/047-dont-s...

hitekker 3y ago
I'm pretty skeptical of what Sinofsky says. Back in the day, former Microsoft employees called out the differences between what he said and what he did, i.e. "Don't ship the org chart" -> his own org ships the org chart. https://news.ycombinator.com/item?id=4778996 https://news.ycombinator.com/item?id=4778996 https://news.ycombinator.com/item?id=4776031 https://news.ycombinator.com/item?id=4776031
- canucker2016 3y ago
  One of the hilarious exchanges (pun intended) that happened on Sinofsky's blog concerned MS Exchange. The executive-level view of events is vastly different from the actual events. tl;dr: Stevesi (Technical Assistant to BillG): Mgmt forced Exchange to use NT Directory (followed by glowing description of the NT directory) DonH (Exchange Directory dev lead/ later Active Directory dev lead): No, NT was late, and eventually canceled NT Directory. Exchange wrote and shipped our own Directory and then moved the code to NT to use as the base for Active Directory. Stevesi prevaricating about high-level executive view of the interaction of NT vs Exchange directory. DonH: No, that's wrong. NT provided nothing. Exchange created an email-specific directory. I used that to make Active Directory. Water flowed uphill not downhill. from https://hardcoresoftware.learningbyshipping.com/p/021-expanding-breadth-versus-coherency https://hardcoresoftware.learningbyshipping.com/p/021-expand...: "That proved to be a defining moment because deploying a directory was hugely complex and there was no way EMS could do it twice. In one of the rare times an architectural choice was pushed to a team, using the directory from NT became a requirement for EMS. Many others supported this, including the Server leadership. It was to them as natural as pushing Excel to use Windows—the directory was that core to NT Server—while sharing files and printers was the baseline scenario, it was the directory that brought deep enterprise value to customers. For the better part of the following year or more, EMS would not speak well of using the NT Directory, and conversely the NT team felt that EMS was trying to use the Directory in ways it was not designed to be used. This sounded to me a lot like getting Excel to work on Windows, and it played out exactly that way. Had EMS not used NT Directory, it is likely Directory never would have achieved critical mass as the defining app for the client-server era (and remained the cloud anchor for today’s Office 365). And conversely, had the NT team not met the needs of EMS, then the NT Directory would have likely been sidelined by the rising importance of the email directory in EMS. Forcing this issue, while it might be an exception, only proved the strength of a strategic bet when it is made and executed. Still, it was painful." Comment from DonH Apr 22, 2021, at end of blog entry: "Speaking as the dev lead for the Exchange Directory (1991-1996) and later on Active Directory (1996-2005), there's a lot wrong with this chapter. NT's approach to functional directory services in the early 90's was "wait for Cairo. they're building one", which meant that we in Exchange had to build our own directory service. When Cairo collapsed (late 1995) Exchange and NT struck a deal so that once Exchange 4.0 shipped (April 1996) one of my developers and I brought a copy of the Exchange Directory source code over to Windows, and we built Active Directory out of that. Exchange in no way "bet on" the NT Directory; we essentially built the replacement for it in order to get the features we needed. Ask me if you need details. However, the part about endless repeated pressure to build everything (specifically including the directory) on top of SQL is entirely accurate. I'm only moderately annoyed that I had to pay ten bucks to post this correction." Second comment from DonH: "You're missing the point that there was no NT Directory. The strategy given to us was "use the NT directory, which is the Cairo directory. Sorry that doesn't exist yet, so Exchange might need to cobble something together for its first release." I built that something, and later went on to use it to fill the directory service shaped hole in Windows. Presenting this as Exchange leveraging the NT Directory might be polite, but it is definitely not accurate. And although I remain eternally grateful to LDAP for saving me from COM I completely agree about omitting it from the history."

ivan_gammel 3y ago

Many people refer to Conway's law here, but I'd argue that this law is true only for the static organization design, where structure is rigid and never changes. This law and and the title of the link hide much more important dependency: organization is a function of business requirements. System design is a function of them too. It MAY happen that organization is designed first, but it is not necessarily the case. Organization changes happen all the time and systems tend to stay during those changes. Many companies have subdivisions organized around the customer journey or certain product topics, e.g. Acquisition tribe or B2B business unit. Those structures work very well and do not reflect the Conway's law (system architecture required in this case is often org-wide and modular, requiring all org units to follow the same design approach).

btbuildem 3y ago
It's interesting to think of this in conjunction with the Peter Principle. In any org that's existed long enough, you will have a "crust" of people who have been promoted until they're too incompetent for their position. If long enough time elapses, these incumbents will account for most of the decision makers in the org chart, from the root on down. Given how incentives and motivations change with seniority, it's not a far stretch to assume that they will want to remain where they are - cannot be promoted any further, and would rather not lose current status. I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.
MajimasEyepatch 3y ago
Conway's law would still apply in a company where the org chart is changing. Obviously old systems don't disappear in a reorg, but new ones will reflect the communication structures at the time that they were built. In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously. In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.

alberth 3y ago

Domino Pizza tracker The article is centered around the pizza tracker, but I thought that tracker was fake. Just for illustrative purposes. Is it not? https://www.the-sun.com/money/6927297/dominos-pizza-tracker-different-than-expected/amp/ https://www.the-sun.com/money/6927297/dominos-pizza-tracker-...

Larrikin 3y ago
I'm sure some MBA douche presented the calculation at headquarters to save the money by making it fake, but when it was first released there was a massive campaign showing Domino's workers getting the orders printed out and hitting buttons at various parts of the process that actually did update the tracker.
- subroutine 3y ago
  I'm not sure about Dominos, but the last time I ordered Papa Johns, the pizza tracker had a disclaimer that said it was "for entertainment purposes only, and does not reflect actual events"
diggan 3y ago
That article is basically "they say, they say" argument between two Twitter users, not sure one could come to any conclusion based on that. It's also a The Sun article, FWIW. I've always thought the tracker was real, at least here in Spain (it looks different than the US one in the article pictures), as it always seems to have changed at different intervals. Could also be just randomized a bit I guess. Long time ago I ordered from Domino anyways.
8organicbits 3y ago
> includes the name of the employee baking each pizza Yikes, I wouldn't put that info online. What's the point?
gibbitz 3y ago
My former boss wrote the first version of it when he was working for Crispin-Porter + Bogusky. He claimed that internally Domino's already had the infrastructure for their own telemetry and logistics and putting a python API on top of it to connect to the web was a no-brainer. To hear him tell it, it was his idea. Of course I later worked for a company that was helmed by the former Domino's CEO at that time who claimed it was his idea. Based on the technical backstory I would believe my former boss over the CEO. Of course the existing telemetry at Domino's could be garbage or fake...

shubhamjain 3y ago

The whole post is based on a questionable assumption that Domino Pizza Tracker accurately reflects the status of the Pizza, when it could just be a dumb timer based on a statistical average. Sure, the Pizza Delivery person in the last step has to be accurate, but that's simpler than tracking if the Pizza is in the oven. As for the point itself, I think the real-time status tracking is a very, very small subset of UIs. Yes, it's difficult to deliver if the organization isn't designed around this, but most sucky UIs aren't limited by not having the data.

rileymat2 3y ago
Its not perfect, but at Starbucks, the “working on your drink” notification comes when they rip it off the machine, so it is kind of real time. (Kind of, because often they rip off 3 or 4 and stick them to the wall)
velcrovan 3y ago
> it could just be a dumb timer based on a statistical average The post makes this point explicitly. It doesn’t sound like you read the whole thing.
- shubhamjain 3y ago
  My bad! I raced through the article, skipping the important bit.
deleted 3y ago
[deleted]

btbuildem 3y ago

Seeing all the mentions of Conway's Law here jogged something in my mind -- could one assert the converse and "reverse engineer" the org structure of a company by examining the systems it has designed? This could be super useful when considering the next place of employment for example; the organizational dysfunctions and idiosyncrasies only become apparent once you've jumped in with both feet.

01HNNWZ0MV43FF 3y ago
Legend has it that Google produces a new chat program every year or two when a high-up manager wants a promotion. Microsoft also seems to have generational UI revamps. There's a funny bathtub curve where Win32 has outlived many of its replacements.
db48x 3y ago
Yes, you can! You can even tell when the organization was changed, since many complex systems are upgraded over time. The example I like best is the Windows volume control(s), as pointed out by Casey Muratori (https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY).

deepsun 3y ago

> where the step from “order received” to “pizza in the oven” happens only because of a timer in the UI Then don't lie. Instead of the status, just say outright that it takes up to 5 minutes for the pizza to get in the oven. And show a timer.

hcarvalhoalves 3y ago

Sometimes, UIs are designed with unrealistic expectations and mismatches of how processes work in reality. This is maybe lost on today’s “native digital” generation, but anyone who worked at organizations a while back should understand this intuitively. Back then, processes inside companies where paper-driven, a variation of “produce some kind of document, pass it along to another department, get a stamped copy/receipt to prove it’s been done”. I always use this example when designing architectures and UIs: if you couldn’t design the same process as paper being passed around, the design is missing something. You need to really grok the company structure and the domain to design something sensible.

couchand 3y ago
Yes! And, the killer feature of paper that no digital UI has yet to fully capture is the margin. If your business process doesn't have a form field for some data, but the person on the ground understands that it's valuable, it's naturally scribbled onto the margins, and then worked into the next version of the form. If you're using nearly any digital UI, the feedback loop (if it exists at all) is a side channel. More businesses should just use paper.
- 01HNNWZ0MV43FF 3y ago
  If PDF editing tools were a little better and the average users' file name habits weren't ghoulish we could have digital paper.
  - BeFlatXIII 3y ago
    What naming habits would you like to see the average user adopt?
    - doubled112 3y ago
      If I never see people prepending and appending seemingly random versions again, I'd be thrilled. draft_document.pdf document.pdf final_document.pdf final_final_document.pdf document_final.pdf document_v2.pdf final_final_document_v3.pdf Which one do I use?

kylecordes 3y ago

I have noticed that the Panera Bread status tracker used to provide good information, but doesn't anymore. It frequently says an order is done while it is still being worked on. Might be a UI/Organization mismatch, as described in this article. Or maybe it's the staff intentionally marking things done early, to game metrics expectations from management.

deleted 3y ago

[deleted]

tsylba 3y ago

The Domino's pizza tracking bits is a funny one for those whom had read Snowcrash, where a whole earlier section of the book is about the advancement of the pizza delivery industry. I don't know, it seem to me the 90s had a very dystopian view of future Pizza Hut. « The Deliverator stands tall, your pie in thirty minutes or you can have it free, shoot the driver, take his car, file a class-action suit. The Deliverator has been working this job for six months, a rich and lengthy tenure by his standards, and has never delivered a pizza in more than twenty-one minutes. [..] Pizza delivery is a major industry. A managed industry. People went to CosaNostra Pizza University four years just to learn it. Came in its doors unable to write an English sentence, from Abkhazia, Rwanda, Guanajuato, South Jersey, and came out knowing more about pizza than a Bedouin knows about sand. And they had studied this problem. Graphed the frequency of doorway delivery-time disputes. Wired the early Deliverators to record, then analyze, the debating tactics, the voice-stress histograms, the distinctive grammatical structures employed by white middle-class Type A Burbclave occupants who against all logic had decided that this was the place to take their personal Custerian stand against all that was stale and deadening in their lives: they were going to lie, or delude themselves, about the time of their phone call and get themselves a free pizza; no, they deserved a free pizza along with their life, liberty, and pursuit of whatever, it was fucking inalienable. »

bjnewman85 3y ago

Umm, the argument in the article seems self-defeating. UI=f(org) except we end up with the same UI with radically different orgs because we can just f() over the differences with dark design patterns and users can't tell the difference. I can show you anything in a UI - only good orgs can develop valuable products from those UIs.

vonnik 3y ago

This is a variation of "you ship your org chart." After hearing the outbound version of this truism, I discovered that the inbound version is also true; ie "you buy your org chart." Anyone selling to v large organizations, corporate or government, will know what I mean. Bloated and dysfunctional orgs with eternal sales cycles buy from bloated and dysfunctional orgs that can survive eternal sales cycles, and which are willing to sell bloated and dysfunctional products to satisfy arbitrary criteria. This is one of many reasons why startups have a hard time selling to very large orgs.

cratermoon 3y ago

I order from Domino's now and then. I've noticed that someone named Scott seems to be working preparing pizzas at all hours on all days. It didn't take me very long to figure out that the tracker was just putting in a placeholder event. The actual delivery tracker seems to work OK, though.

deleted 3y ago

[deleted]

jbs789 3y ago

So the output of an organisation is a function of the organisation. Or the amount of effort you put into something affects the outcome. Shocking.

alxmng 3y ago

“To the extent that the business takes place in software, designing the software is designing the business.” @mulegirl from Twitter