9 ms·

Never attribute to stupidity what is adequately explained by opportunity cost

288 points by focodev 6y ago

Rerarom 6y ago
Like when I asked my friend when we were kids: why don't you have money? And he said we have money, but it's for something else. I said well what could be more important than this? (Forgot what "this" was, most probably a new PC.)
leoedin 6y ago
This rings really true with my experience at a startup. Everyone involved in the product could see it's weaknesses, we just didn't have the manpower to change them. I've definitely fallen into the "attribute to malice/stupidity" trap as well, even when I know that the people responsible are working flat out, if you're not in the trenches it's so easy to say "but it's so simple! I could do it in an hour". It's something you have to constantly keep in check. Honestly, I think the prioritisation thing is absolutely the most important thing any team or company can do. The person working on a feature almost never has the overall context to accurately prioritise. The next feature or bug on whatever they're working on will always feel more important than someone else's problem. Building a working environment which empowers people to work towards a common goal - and not just whatever feels important to them in the moment - is really hard.
- branko_d 6y ago
  On the other hand, the importance of a specific task can sometimes be adequately assessed only by a narrow group of people, making it difficult to convey the importance to the larger organization. This usually falls in the realm of performance, "rare" bugs (especially non-deterministic bugs) and code quality. Such "invisible" work may be difficult to justify over "visible" work, yet is crucial for the long-term quality of the product. There is a decades-old ERP system (that shall remain unnamed), which to this day doesn't use foreign keys in its database. The consequences of this are not immediately visible, but are very serious in the long term, including data corruption (which I have actually seen with their customer) and (somewhat counter-intuitively) performance (https://stackoverflow.com/a/8154375/533120 https://stackoverflow.com/a/8154375/533120). Having had a glimpse of their internal culture, I'm not surprised. Any "foreign key champion" would have been quickly assigned to "more important" tasks.
- darkerside 6y ago
  > "but it's so simple! I could do it in an hour" This is such a common gripe, and I agree it's grounded in a lack of perspective. It reminds me of an image that helped me quit smoking. When you pick up a cigarette, imagine that a string is connected to every other cigarette you will smoke for the rest of your life, in a chain that stretches on into the future. You're not just picking up one cigarette. And similarly, you're not just picking up one hour of work, because there are 100 other features that fall into the same box.
- withinboredom 6y ago
  > but it's so simple! I could do it in an hour That's when you clone their project and set aside four hours on a weekend/downtime and open a PR (if you happen to finish in four hours)! I try to commit to fixing annoying bugs whenever I can spare a wee bit of time. Sometimes my attempt is a hacky or not-so-great solution, but it's close enough that those close to the project can realize that it only needs a few more lines in exactly the right place or choose to ignore it.
eythian 6y ago
I usually find that when I have to go "why is this the way it is, that's stupid!" I usually end up finding out that there is (sometimes was) some design constraint I wasn't aware of that caused to to need to be that way, and actually it makes sense.
- artsyca 6y ago
  Hear hear and that is usually some trifling corporate rumour that keeps circling and lending itself legitimacy but nobody recognizes as hearsay and everybody accepts as fact
lowdose 6y ago
If something is more valuable than the opportunity costs it is stupidity not to pursue it .If something is less valuable than the opportunity cost it is stupid to mention.
mcqueenjordan 6y ago
This is such an important concept. I was just explaining this to product/leadership the other week: "It's not a matter of convincing me we should do this. Obviously, we should. But we also have a hundred other things that we should do, and a few dozen things that we need to do. So it's not a discussion of 'should we'; it's a discussion of understanding how important this thing is in relation to all of the other things." Triage and prioritization is hard.
- chris_st 6y ago
  I had a kind of... manipulative co-worker who often tried to work around the Product Owner. He'd come into my office and ask, "Can we do <some feature>?", hoping to trigger my inner engineer to be interested in how to solve that problem. He finally got tired of me saying, "Given enough time and resources, yes, we can do pretty much anything! Talk to <Product Owner> about what we SHOULD do."
  - tehlike 6y ago
    And probably the moment you do it, he'd take all the credit from you too.
    - chris_st 6y ago
      Well, no, he wasn't that much of a jerk, thankfully.
      - tehlike 6y ago
        Good. When you said manipulative, it suddenly brought back memories :)
- artsyca 6y ago
  Did you ever think you'd get here when you were a kid building spaceships out of lego?
- JoeAltmaier 6y ago
amelius 6y ago
> I've found that neither malice nor stupidity is the most common reason when you don't understand why something is in a certain way. Instead, the root cause is probably just that they didn't have time yet. Ok, let's leave security for later!
- Ma8ee 6y ago
  And even that is sometimes the right decision. I personally experienced an important delivery being delayed several days because the tech lead wasn’t happy with the security settings on the database server. If the DB was accessible outside our internal network or contain any information that wasn’t publicly available, I would have understood.
  - wccrawford 6y ago
    Someone that concerned with security is either fanatical, or they've been burned by it before. I also will not sign off on security concerns unless they are correct. I'm happy to let management override me, but I won't back down and say things are finished when they aren't. IMO, your tech lead wasn't the problem here. Their boss was. Their boss decided that the security was more important than the delivery date, or they decided that they didn't care enough to get involved, which amounts to the same thing.
trwhite 6y ago
You often hear people in engineering teams say something to the effect of "I can't understand why this was built this way. It's been done stupidly", but invariably there's some key piece of contextual information that's missing like, as you say, there simply wasn't enough time. I also wrote about this recently: https://timwhite.digital/building-software-sharing-knowledge https://timwhite.digital/building-software-sharing-knowledge
- jaclaz 6y ago
  Well, the "I can't understand why this was built this way. It's been done stupidly" can also be a case of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
  - trwhite 6y ago
    Yes, exactly. The point I make in my article is that stupidity isn't at all as common a reason (for why something's been done a certain way) as we'd like to think it is. I think the true split is about 80/20. This is from someone who's had the [dis]pleasure of working on all manner of steaming piles of rubbish. If there are any Junior devs reading this, Chesterton's Fence is a great concept to understand and abide by!
  - artsyca 6y ago
    When every comma and semi colon in a document of code can be a potential Chesterton's fence you have to wonder how any progress can ever be made
- withinboredom 6y ago
  > I can't understand why this was built this way. It's been done stupidly Or that the way to do it better simply didn't exist back then :)
- pnw_hazor 6y ago
  Even though I had plenty of experience in leadership roles, I preferred to join startups as a senior dev. Later, after I understood the lay of the land, I would move into leadership roles as needed. This helped me develop relationships with other devs, QA, ops, etc. Also, I could learn or discover the reasoning behind trade offs and compromises that were made before I proposed changes. One time I went direct into a director/manager lead role. It was a nightmare, some on the team thought I didn't know what I was talking about -- even though they were not using source control until I brought it up during my interview. They had not been exposed to professional software development before my arrival and took little stock in my advice/leadership.
k__ 6y ago
"It might seem obvious the way I put it that opportunity cost is the thing to blame. But it's not." You just have to look at the k8s hype to see that it's not. In this industry, I often have the feeling that people are fetishizing complex solutions even if the problem at hand doesn't require them. But I have to admit, it's not easy to focus on the problem space and really work out what is needed. Most people do too much or not enough.
bauk 6y ago
Similarly, people sometimes don't change their opinion on an issue - not because they're stupid, but because changing your mind about something takes work, work takes resources, and these resources are already invested in something you perceive as important.
runawaybottle 6y ago
I mostly disagree with this. At a certain point it becomes inexcusable, and I personally never judge them as being stupid or lazy, I just attribute it to lack of empathy. It’s painful for people that have to regularly deal with something not straightforward (over complex) or just plain old messy (no concern over what it would be like to revisit the code for anyone, even themselves). Ruins my day(s), and it takes some mental gymnastics to justify serial offenses of this kind (e.g We got it done , that’s what matters - great, but you slowed down velocity at every later stage). Lastly, I think when you find yourself asking ‘why is it done this way’, you’ll notice it’s a pattern. It’s never a few pieces here and there where you can reasonably understand, it’s always endemic throughout the codebase. So sure, not stupidity, just a pungent disregard for others.
- artsyca 6y ago
  False corporacy makes people do stupid things A casual company culture is an implied pungent disregard for others and it comes with its own pungent smell of entitlement too
dade_ 6y ago
Some of the worst managers I have worked for didn't understand opportunity cost. Good idea to test during a job interview or before starting a partnership. Nothing more maddening than working for an Ahab chasing whales.
- artsyca 6y ago
  Or a canine chasing tails
ImaCake 6y ago
What if the opportunity cost is borne out of malice? I briefly worked as a quality control microbiologist at a manufacturing facility. We were constantly understaffed and unable to meet requirements. Heaps of missed opportunity to improve things. But my feeling was the the company didn't care beyond the facade of having some micro testing. There was always talk of improving things, but things never improved.
- aaaaarghZombies 6y ago
  > What if the opportunity cost is borne out of malice? Seems to work for the labor party.
austincheney 6y ago
As a JavaScript developer I find the stupidity versus opportunity cost virtually impossible to distinguish. After all, its how I involuntarily became a developer in the first place. I was hired by Travelocity late in 2007 to be a designer. In early 2008 I was a UI developer and if I wanted to continue to be employed I would have to figure it out. JavaScript developers, at least competent ones, were nearly impossible to find, so it made sense for the company to convert me into a developer instead of struggling to hire somebody who probably couldn't do the job anyways. Keep in mind this is before jQuery became popular, before JavaScript became fast, and before massive MVC frameworks did your entire job for you. Competent JavaScript developers were nearly impossible to find for what companies were willing to pay. Also, keep in mind that at that time JavaScript developers earned about half what a Java developer earned but had a wider distribution of responsibilities to account for. My incompetence that first year writing logic was a profitable opportunity cost to the employer. As an aside I can remember Google Web Toolkit (GWT) from that time. It would compile Java logic to JavaScript, which was great for barely competent Java developers who couldn't figure out JavaScript. The compiled JavaScript was garbage though. The logic was a mess that often broke. The people who generated that code were afraid of it and hid from it leaving nobody to own or maintain it. It was like some horrid combination of pride, insecurity, hubris, and negligence rolled up in a ball. Was this an opportunity cost or just stupid, it is a challenge to distinguish. Fast forward to modern times and people who write JavaScript are easy to find and are paid much better. Actual JavaScript developers are still almost as rare though. Most people who write JavaScript are not actually JavaScript developers, but rather something like: Angular, React, or Vue developers. They do not write original code, but supplement a framework. If you put a gun to these guys heads and told them they had to write an application without their favorite framework they would happily take the gun from you and shoot themselves in the face. They have no idea what the DOM is, how to architect anything, and in many cases writing any original logic scares them to death. In many cases people who write JavaScript have absolutely no idea what to write, so they only write browser facing single page applications, because that is the preference of their pet framework. To be fair some of the React developers might possess some vague half notion about the DOM, but they would call it a virtual DOM and get angry when I ask them to find "virtual DOM" in the standard DOM specification. In fact many technical requests that are explicitly outside the immediate documentation of their favorite pet framework might make these developers immediately angry (inwardly insecure). This folly is commonly known and accepted as an opportunity costs so employers set the expectations very low and don't ask for such things. The stupidity and incompetence are also distinguished by hiring employers during hiring and candidate selection whether they are looking for a Node.js developer or a UI developer even though its all the same language. The better pay and frequent incompetence are opportunity costs, because somebody has to write this code. The business need is present and so factors are adjusted to ensure delivery of necessary business solutions while reducing hiring risks. It made sense to hire people who could get by just writing minimal logic over a framework tool, because developers are interchangeable assets of the business that come and go rapidly in the marketplace. When there is a shortage of talent you take what you can and ensure it is commonly replaceable. It should also be stated the conditions for hiring developers were well in the developers' favor because the business need was clear and businesses could afford to hire more people while enjoying the longest running bull market in history. I suspect, though, this party is over. We now exist in a period of rapid economic contraction unlike anything in history. Before the recent bull market developers primarily existed to provide automation. The value of most developers was in the reduction of expenditure on the employer's internal operating costs. During this bull market that value became lost as the lines between automation and product creation frequently blurred. Regardless employers just knew they need people to write code and could happily afford it. COVID has put many developers out of work and economists are anticipating the economic hardships will continue for about 2 more years. From a business perspective developers are expensive cost centers. Developers do not add to the revenue of the employer. They only exist to substitute business expense for automation. The people who actually generate revenue are called something like sales, marketing, or merchandising. So, for a hiring manager of a business struggling to stay afloat why would they hire 12 barely competent people who write a few lines of code here and there for a framework SPA when instead they could hire 2 or 3 developers at a slightly hire rate that focus on automation in general? In other words the safe expectation moving forwards is to expect that developers will require more from fewer developers or will find a completely different medium with which to engage their users/clients. With many developers suddenly out of work talent is no longer rare. The opportunity costs have drastically changed in response to market pressures. The employers who will most rapidly adapt their hiring and use of developers are those under greatest financial pressure. The employers who are currently safe from market pressures, whether by their essential status or cash liquidity, will not feel this pressure and will become the new dinosaurs as they retain older and less efficient ways of shipping products.
Geeflow 6y ago
I believe this is one of those things that are really hard to understand unless you have experienced it first hand. Although I always knew how important prioritization is, I understand it way better since working on my resource-constrained side project. You often fail to appreciate just how many obviously good things you can't do because there are even more important things to do. Or, to quote Steve Jobs: "People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are."
- nicbou 6y ago
  It's much more obvious with side projects because there is no one else to blame. You have a complete view of the picture. I find personal projects very humbling. Even with no one stepping on my toes or setting unrealistic requirements, I still make dumb mistakes and write subpar code.
firebird84 6y ago
His statement about bigcos doesn't really jibe with mine. Bigcos are just as concerned with opportunity cost as startups, at least if they're concerned about earnings at all or are run well. You will not have headcount to attack all the problems you have at once, and you'll constantly be chasing revenue/COGS-R opportunities instead of fixing those UI glitches QA found 2 years ago that have workarounds. The day you stop chasing opportunities is the day your headcount gets taken away. It's simply not worth paying someone 6 figures to tackle those issues.
- jefftk 6y ago
  Startups will often have many obvious relatively simple things they're not doing. They're moving very quickly, but they have a small team and have to ruthlessly prioritize. A larger company is generally not moving as quickly, and the scale of the things that they're choosing not to do for opportunity-cost reasons gets much smaller. I worked for a money transfer startup at one point. You could use it on Android and iOS but not on desktop/web. We just hadn't gotten to it yet. If they're successful but still mobile-app only in five years, though, I'll expect that it's for reasons like "we looked into web but fraud rates were much higher" instead of it just being a matter of priorities.
JanisL 6y ago
I worked with a company last year that consistently made poor decisions due to lack of resources, especially time. Sometimes "opportunity cost" was used as an excuse for a lot of things. Now sure if you have a few different immediate options and a lack of capacity you will be forced to choose certain options and ignore others. Scarcity is a real thing and I'm not arguing otherwise. But the bit that might be classified as stupid was that very little thought was given to hiring or any form of capacity planning. As such I think just categorizing this as "opportunity cost" would be missing a very important part of the bigger picture. People can make decisions that impact the amount of resources that are available and over a longer period this is especially important. If you consistently find that you are passing up on profitable opportunities it shows that you may have a very profitable situation to hire people, if you don't pay any attention to that you risk making opportunity costs a self fulfilling prophecy.
- wefarrell 6y ago
  It sounds like they were focusing on the urgent at the expense of the important: https://www.eisenhower.me/eisenhower-matrix/ https://www.eisenhower.me/eisenhower-matrix/
  - ghaff 6y ago
    Yes, although note in the Eisenhower matrix, you "delegate" urgent but less important tasks. If there's no one to delegate to, that falls apart a bit. Now, if you're so under-resourced that you're doing nothing but putting out fires, that's a problem. And you probably have to add resources (of whatever type including delegating to a third party), fix root causes, or decide that what you're treating as urgent really isn't.
artsyca 6y ago
Inefficiency is a form of stupidity and always being busy is a form of inefficiency
sfvisser 6y ago
I don't get the use of the terminology here. Opportunity cost is the cost associated by not reaping the benefits of an alternative not being picked. This is a cost from the perspective of the party making the choice. So in this story, 'opportunity cost' is not an explanation why something didn't happen. It is a side effect of something not happening. You could say the real opportunity cost in this story is the startup teams having a bunch of unhappy users. The explanation for the missing features is simply: they did something else. So better: "Never attribute to stupidity what is adequately explained by prioritisation"
- brownbat 6y ago
  Uncanny. I was also going to recommend that, maybe "ruthless prioritization," to emphasize that everyone is constantly busy and that these choices are sometimes unoptimizably hard. It would also draw a bigger distinction between the "strategic" decisions he describes at bigcos (which also involve opportunity costs!) Terminology aside, I did think he made a good point.
- doodpants 6y ago
  Yes, but another way of looking at it is that if you prioritize A over B, it's because the opportunity cost of not doing A would be greater than the opportunity cost of not doing B. So "prioritization" is another way of saying "minimizing opportunity cost".
  - sfvisser 6y ago
    Sure, but talking about the opportunity cost of the thing you did pick feels backwards to me. Also, prioritization is not only minimizing cost, you’re probably also maximizing reward. So the calculation is more complicated anyways.
    - adrianmonk 6y ago
      I didn't see where the article talks specifically about which thing has an opportunity cost. As far as I can tell, it just says opportunity cost is the relevant phenomenon and leaves it to the reader to figure out which things have a cost and how all the math works out on that.
luckylion 6y ago
"Listen, we just had better things to do than securing our database and customer data. It's not that we don't care about the effect this leak has on the affected individuals, it's just that you can't make money by providing secure systems, so we prioritized animated emojis higher"
harimau777 6y ago
The issue that I see is that the benefits of implementing something the "stupid" way (e.g. it's faster or easier to implement) are often enjoyed by different people than those who have to bear the associated future pain.
- ReactiveJelly 6y ago
  Then it becomes an externality. Why should sales stop littering when development is the one cleaning up the highway?
bernulli 6y ago
This is then made even more frustrating due to the asymmetry when the opportunity cost for you for not having your problem fixed is much higher than for the person you are trying to reach. Or, more succinctly, asking `Who has the problem?' has helped me over the years to adjust my expectations, because more often than not, it is me who has the problem, and not the person I am reaching out to.
- tehlike 6y ago
  The part that sucks the most is when opportunity cost of not doing something is "globally" high, but the other party only optimizes locally for themselves. You will see, especially at work, when you have something that makes a ton of money, but people will be uninterested because it doesn't benefit them as much. At that point you require lots of escalations.
air7 6y ago
Wow. Well put. I'm going to use this. It feels quite true that when analyzing the behavior of any entity (and to a lesser degree, a person) it's rare to take time into account. If something wasn't done it's either stupidity, malice, or something-I-don't-understand. It's refreshing to think that it might just not have happened yet, and perhaps never will because there will always be more important things in the pipeline. So perhaps this idea is a corollary of my own pet aphorism: "Things take way, way, waaayyy longer than you'd think". Everything seems simple and easy until you set to actually do it. The kicker is that even looking back on my own work, I sometimes can't understand "What took me so long?!"
amflare 6y ago
I think the author is saying "opportunity cost" when he really means "ROI".
csours 6y ago
> "People love to conclude that something wasn't done because they are stupid, or possibly lazy. This happens about 95% of the time when you don't know a certain person/team." I used to do plant floor support in a manufacturing plant. Over the radio, people treated me like an idiot. When I walked out to the plant floor they treated me like a genius.
frandroid 6y ago
Y'all missing the most important paragraph in the whole article: > I spent many years working in a satellite office. A lot of the time when I had some deep technical disagreement about something, I'd fly to the main HQ, and go out for dinner with the other team. I wouldn't even talk about technology, just about random stuff. Once they knew me, and realize I was a human (and not a faceless blob), most technical disagreements tended to go away. People are more likely to assume positive intent and not malice/stupidity/laziness. Building relationships is important important to get bug fixed/features built. Bug prioritization isn't a just a technical nor a business exercise. Now, I want to hear which company this is that this guy could just "fly to HQ" (I'm assuming Microsoft Back in the Day) but the geographic gaps aren't always that large... :P
- schnevets 6y ago
  I've always believed telecommuting needs the remote equivalent of the golf course. There are certain human elements that cannot be built over a Zoom call, but do not inherently require a physical presence. I have never started a company and I was hire #76 at my current place, but if I were to start something remote, I would find a game or hobby appreciated by all the founders and make sure that remained a bedrock of our culture.
  - bgilroy26 6y ago
    This is a huge opportunity. It would serve a great need to create a structured, low-pressure activity for potential business partners to participate in as they socialize over video chat. Given the potential to democratize socializing to form business partnerships, it would catch on all on its own as a way to be inclusive during the pandemic in a way that golf never was. Semi-related, I was reading a sociological research paper by Irving Crespi about playing cards in Endicott, NY and in his conclusion, he speculates that people used the structure of playing bridge or what have you in order to more easily tolerate each other's company. He was trying to explain why most card players weren't gambling seriously and I think he was right about structured activities providing a social lubricant analogous to alcohol. Perhaps the eu-social aid of structured activity is even stronger than alcohol because we're given a detailed script to play out and distract ourselves instead of simply taking the edge off of our ability to waste energy over analyzing the social situation.
bobbytherobot 6y ago
I learned a lesson about opportunity costs while worked at an IT company. When I started, the company managed the IT for small companies, most being three to five people companies. We had full control of decisions so we kept them up-to-date with the latest best practices. I'm sure there was a bias of the types of companies who went with us as we charged more than competitors. We started to gain larger clients. We thought that a 5,000 person company would be ahead of the 5 person company when it came to technology. Not so. Here is what we learned: there are political risks for changing technology. A CTO (these are not tech companies) would wait until people were complaining so extremely that people would have to feel that changes were good. It all arose from that bias most people have about change being bad unless it is ten times better.
- pnutjam 6y ago
  This is so true. I've been in plenty of small business that are trying to do the best and their constraints are usually based on the ability of early hires. Big companies have inertia to deal with for every change and once you get burned by something trivial that gets blamed for problems, you get very shy about improvements. I'm in the process of building a system that had to make alot of compromises based on existing expectations. It's probably a year away from being where I want it to be because every change is so slow... It's frustrating to defend these decisions every time someone comes along and notices how hard it is to use the system. I have to explain that every part of the system is broken out currently to find issues and fix them, the end goal is to stack everything together, but right now all the sausage making is on display and frankly it's appalling... (edited for readability) end goal is turning a push button system that had to be carefully monitored for breakage (while it was running after hours) into a staged system that gets checked and verified during business hours, but still fires off after hours.
heymartinadams 6y ago
Bernhardsson’s razor. Someone should make a Wikipedia entry for that.
maerF0x0 6y ago
> Never attribute to stupidity that which is adequately explained by opportunity cost "Why didn't we invest in long term issues?" (say virus research...) Because I can make lots in finance this quarter." As I understand it humans have (at least) 2 really big problems in rational thought: 1) A bias towards the short term and 2) unknown unknowns (cue Nassim Taleb) Never attribute to higher order stupidity that which can be attributed to lower order brain functions.
pnw_hazor 6y ago
In IP law, if I see terrible work product that cost my clients $5-$25K in waste, I try to be charitable and remind myself that sometimes there is context that I am not aware of that may have been the cause. Such context may be client driven immutable deadlines, client-side delays, client-side lack of communication, and so on. In reality there probably was incompetence bordering on malpractice by the prior firm that did the work. But you never know. If $100Ks (and multiple years) have been wasted, I know it is incompetence bordering on malpractice. Especially, if the firms that did the bad work have well known brands. In professions like law, medicine, or professional engineering prioritizing is important and useful but providing shoddy work product or corner cutting should be unacceptable. And often corner cutting is malpractice. In software development I used to push hard to get people to focus on getting from A to B efficiently while using an architecture that supports flexibility rather than over-engineering from the beginning. It seemed to work well. Though I did run into some managers/directors/VPs that would carefully listen to a reasonable proposal and ignore it or in one case do the opposite. I always took that as the sign to move somewhere else. Eventually leading me to go law school.
jessriedel 6y ago
So the fact that I can't filter my Amazon search by price until I choose one of multiple plausible "departments" is attributable to Amazon simply not having enough software engineers to spare for the past decade? I doubt it.
adrianmonk 6y ago
I agree, but only partly. Yes, prioritization is likely the explanation for a lot of things. It's absolutely true that the responsible team cannot do everything you'd wish. But, sometimes there's stupidity at a different level. Just because someone is making an effort at prioritization doesn't mean they are doing a good job of prioritization. It's hard to tell from the outside (where you lack the relevant knowledge), so you're kind of forced into giving them the benefit of the doubt. But sometimes that internal tools bug which they never get around to fixing is eating up 5 minutes of every employee's time every day for 2 years, and it adds up to a lot of wasted time, and they should have prioritized it but they didn't. Maybe because they didn't appreciate what the cost was, or maybe because they had some bias toward certain kinds of tasks, or maybe some other reason.
breischl 6y ago
I tend to agree with this. I do think that this article (as with most) brushes far too easily over the tension between tech debt and new features. It's not uncommon to have a product person (or even team) that spend tons of time doing analysis to find high-value features. When they show up with some slick Powerpoint/Excel thing that says "If we build this feature we make $BIGNUM", it's extremely difficult for some dev (or dev manager) to come up with an effective counterargument for working on tech debt. Partially because it's not their main job, and partially because quantifying the impact of tech debt is extremely difficult. And it's very easy for that to happen every single planning cycle, even while everyone makes appropriate noises about tech debt being super important and we're totally gonna address that but we just can't justify not going for that $BIGNUM cash first! I wish I had a solution for that - I don't. If anybody else does I'd love to hear it. :)
7532yahoogmail 6y ago
There's a lot to like in this article. I like how the author tries to remove manipulative motions (correspondingly paranoia) from the context in hopes people can see truer. Nontheless (I am 25+ years in software dev), - some 20pct of people think the office is where politics and games are played. Thus they try to play it better. That's because openness at the office is usually quite low. Such people are unmoved by push back thinking themselves the smarter, grayer haired guy. Survivors of this kind of BS actually are smart, and do have experience with effective but distorting coping skills - software should be a formal science. It's not almost all the time - the chief issue unaddressed here but smartly lead up to is the management function: as the normal scenario is that resources are vastly drwafed by problems what do we say no to? The management question when examined is complex and when it unfolds to systemic issues that are chiefly human not technical viz any of the corporate histories on quality improvement in the 80s/90s esp with company turnarounds. Ex. Detroit, Xerox, IBM under gerstner. While technical issues remain on the table, sustained under performance is ultimately rooted in management and company culture.

288 points by focodev 6y ago

Like when I asked my friend when we were kids: why don't you have money? And he said we have money, but it's for something else. I said well what could be more important than this? (Forgot what "this" was, most probably a new PC.)

leoedin 6y ago

This rings really true with my experience at a startup. Everyone involved in the product could see it's weaknesses, we just didn't have the manpower to change them. I've definitely fallen into the "attribute to malice/stupidity" trap as well, even when I know that the people responsible are working flat out, if you're not in the trenches it's so easy to say "but it's so simple! I could do it in an hour". It's something you have to constantly keep in check. Honestly, I think the prioritisation thing is absolutely the most important thing any team or company can do. The person working on a feature almost never has the overall context to accurately prioritise. The next feature or bug on whatever they're working on will always feel more important than someone else's problem. Building a working environment which empowers people to work towards a common goal - and not just whatever feels important to them in the moment - is really hard.

branko_d 6y ago
On the other hand, the importance of a specific task can sometimes be adequately assessed only by a narrow group of people, making it difficult to convey the importance to the larger organization. This usually falls in the realm of performance, "rare" bugs (especially non-deterministic bugs) and code quality. Such "invisible" work may be difficult to justify over "visible" work, yet is crucial for the long-term quality of the product. There is a decades-old ERP system (that shall remain unnamed), which to this day doesn't use foreign keys in its database. The consequences of this are not immediately visible, but are very serious in the long term, including data corruption (which I have actually seen with their customer) and (somewhat counter-intuitively) performance (https://stackoverflow.com/a/8154375/533120 https://stackoverflow.com/a/8154375/533120). Having had a glimpse of their internal culture, I'm not surprised. Any "foreign key champion" would have been quickly assigned to "more important" tasks.
darkerside 6y ago
> "but it's so simple! I could do it in an hour" This is such a common gripe, and I agree it's grounded in a lack of perspective. It reminds me of an image that helped me quit smoking. When you pick up a cigarette, imagine that a string is connected to every other cigarette you will smoke for the rest of your life, in a chain that stretches on into the future. You're not just picking up one cigarette. And similarly, you're not just picking up one hour of work, because there are 100 other features that fall into the same box.
withinboredom 6y ago
> but it's so simple! I could do it in an hour That's when you clone their project and set aside four hours on a weekend/downtime and open a PR (if you happen to finish in four hours)! I try to commit to fixing annoying bugs whenever I can spare a wee bit of time. Sometimes my attempt is a hacky or not-so-great solution, but it's close enough that those close to the project can realize that it only needs a few more lines in exactly the right place or choose to ignore it.

eythian 6y ago

I usually find that when I have to go "why is this the way it is, that's stupid!" I usually end up finding out that there is (sometimes was) some design constraint I wasn't aware of that caused to to need to be that way, and actually it makes sense.

artsyca 6y ago
Hear hear and that is usually some trifling corporate rumour that keeps circling and lending itself legitimacy but nobody recognizes as hearsay and everybody accepts as fact

lowdose 6y ago

If something is more valuable than the opportunity costs it is stupidity not to pursue it .If something is less valuable than the opportunity cost it is stupid to mention.

mcqueenjordan 6y ago

This is such an important concept. I was just explaining this to product/leadership the other week: "It's not a matter of convincing me we should do this. Obviously, we should. But we also have a hundred other things that we should do, and a few dozen things that we need to do. So it's not a discussion of 'should we'; it's a discussion of understanding how important this thing is in relation to all of the other things." Triage and prioritization is hard.

chris_st 6y ago
I had a kind of... manipulative co-worker who often tried to work around the Product Owner. He'd come into my office and ask, "Can we do <some feature>?", hoping to trigger my inner engineer to be interested in how to solve that problem. He finally got tired of me saying, "Given enough time and resources, yes, we can do pretty much anything! Talk to <Product Owner> about what we SHOULD do."
- tehlike 6y ago
  And probably the moment you do it, he'd take all the credit from you too.
  - chris_st 6y ago
    Well, no, he wasn't that much of a jerk, thankfully.
    - tehlike 6y ago
      Good. When you said manipulative, it suddenly brought back memories :)
artsyca 6y ago
Did you ever think you'd get here when you were a kid building spaceships out of lego?
JoeAltmaier 6y ago

amelius 6y ago

> I've found that neither malice nor stupidity is the most common reason when you don't understand why something is in a certain way. Instead, the root cause is probably just that they didn't have time yet. Ok, let's leave security for later!

Ma8ee 6y ago
And even that is sometimes the right decision. I personally experienced an important delivery being delayed several days because the tech lead wasn’t happy with the security settings on the database server. If the DB was accessible outside our internal network or contain any information that wasn’t publicly available, I would have understood.
- wccrawford 6y ago
  Someone that concerned with security is either fanatical, or they've been burned by it before. I also will not sign off on security concerns unless they are correct. I'm happy to let management override me, but I won't back down and say things are finished when they aren't. IMO, your tech lead wasn't the problem here. Their boss was. Their boss decided that the security was more important than the delivery date, or they decided that they didn't care enough to get involved, which amounts to the same thing.

trwhite 6y ago

You often hear people in engineering teams say something to the effect of "I can't understand why this was built this way. It's been done stupidly", but invariably there's some key piece of contextual information that's missing like, as you say, there simply wasn't enough time. I also wrote about this recently: https://timwhite.digital/building-software-sharing-knowledge https://timwhite.digital/building-software-sharing-knowledge

jaclaz 6y ago
Well, the "I can't understand why this was built this way. It's been done stupidly" can also be a case of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
- trwhite 6y ago
  Yes, exactly. The point I make in my article is that stupidity isn't at all as common a reason (for why something's been done a certain way) as we'd like to think it is. I think the true split is about 80/20. This is from someone who's had the [dis]pleasure of working on all manner of steaming piles of rubbish. If there are any Junior devs reading this, Chesterton's Fence is a great concept to understand and abide by!
- artsyca 6y ago
  When every comma and semi colon in a document of code can be a potential Chesterton's fence you have to wonder how any progress can ever be made
withinboredom 6y ago
> I can't understand why this was built this way. It's been done stupidly Or that the way to do it better simply didn't exist back then :)
pnw_hazor 6y ago
Even though I had plenty of experience in leadership roles, I preferred to join startups as a senior dev. Later, after I understood the lay of the land, I would move into leadership roles as needed. This helped me develop relationships with other devs, QA, ops, etc. Also, I could learn or discover the reasoning behind trade offs and compromises that were made before I proposed changes. One time I went direct into a director/manager lead role. It was a nightmare, some on the team thought I didn't know what I was talking about -- even though they were not using source control until I brought it up during my interview. They had not been exposed to professional software development before my arrival and took little stock in my advice/leadership.

k__ 6y ago

"It might seem obvious the way I put it that opportunity cost is the thing to blame. But it's not." You just have to look at the k8s hype to see that it's not. In this industry, I often have the feeling that people are fetishizing complex solutions even if the problem at hand doesn't require them. But I have to admit, it's not easy to focus on the problem space and really work out what is needed. Most people do too much or not enough.

bauk 6y ago

Similarly, people sometimes don't change their opinion on an issue - not because they're stupid, but because changing your mind about something takes work, work takes resources, and these resources are already invested in something you perceive as important.

runawaybottle 6y ago

I mostly disagree with this. At a certain point it becomes inexcusable, and I personally never judge them as being stupid or lazy, I just attribute it to lack of empathy. It’s painful for people that have to regularly deal with something not straightforward (over complex) or just plain old messy (no concern over what it would be like to revisit the code for anyone, even themselves). Ruins my day(s), and it takes some mental gymnastics to justify serial offenses of this kind (e.g We got it done , that’s what matters - great, but you slowed down velocity at every later stage). Lastly, I think when you find yourself asking ‘why is it done this way’, you’ll notice it’s a pattern. It’s never a few pieces here and there where you can reasonably understand, it’s always endemic throughout the codebase. So sure, not stupidity, just a pungent disregard for others.

artsyca 6y ago
False corporacy makes people do stupid things A casual company culture is an implied pungent disregard for others and it comes with its own pungent smell of entitlement too

dade_ 6y ago

Some of the worst managers I have worked for didn't understand opportunity cost. Good idea to test during a job interview or before starting a partnership. Nothing more maddening than working for an Ahab chasing whales.

artsyca 6y ago
Or a canine chasing tails

ImaCake 6y ago

What if the opportunity cost is borne out of malice? I briefly worked as a quality control microbiologist at a manufacturing facility. We were constantly understaffed and unable to meet requirements. Heaps of missed opportunity to improve things. But my feeling was the the company didn't care beyond the facade of having some micro testing. There was always talk of improving things, but things never improved.

aaaaarghZombies 6y ago
> What if the opportunity cost is borne out of malice? Seems to work for the labor party.

austincheney 6y ago

As a JavaScript developer I find the stupidity versus opportunity cost virtually impossible to distinguish. After all, its how I involuntarily became a developer in the first place. I was hired by Travelocity late in 2007 to be a designer. In early 2008 I was a UI developer and if I wanted to continue to be employed I would have to figure it out. JavaScript developers, at least competent ones, were nearly impossible to find, so it made sense for the company to convert me into a developer instead of struggling to hire somebody who probably couldn't do the job anyways. Keep in mind this is before jQuery became popular, before JavaScript became fast, and before massive MVC frameworks did your entire job for you. Competent JavaScript developers were nearly impossible to find for what companies were willing to pay. Also, keep in mind that at that time JavaScript developers earned about half what a Java developer earned but had a wider distribution of responsibilities to account for. My incompetence that first year writing logic was a profitable opportunity cost to the employer. As an aside I can remember Google Web Toolkit (GWT) from that time. It would compile Java logic to JavaScript, which was great for barely competent Java developers who couldn't figure out JavaScript. The compiled JavaScript was garbage though. The logic was a mess that often broke. The people who generated that code were afraid of it and hid from it leaving nobody to own or maintain it. It was like some horrid combination of pride, insecurity, hubris, and negligence rolled up in a ball. Was this an opportunity cost or just stupid, it is a challenge to distinguish. Fast forward to modern times and people who write JavaScript are easy to find and are paid much better. Actual JavaScript developers are still almost as rare though. Most people who write JavaScript are not actually JavaScript developers, but rather something like: Angular, React, or Vue developers. They do not write original code, but supplement a framework. If you put a gun to these guys heads and told them they had to write an application without their favorite framework they would happily take the gun from you and shoot themselves in the face. They have no idea what the DOM is, how to architect anything, and in many cases writing any original logic scares them to death. In many cases people who write JavaScript have absolutely no idea what to write, so they only write browser facing single page applications, because that is the preference of their pet framework. To be fair some of the React developers might possess some vague half notion about the DOM, but they would call it a virtual DOM and get angry when I ask them to find "virtual DOM" in the standard DOM specification. In fact many technical requests that are explicitly outside the immediate documentation of their favorite pet framework might make these developers immediately angry (inwardly insecure). This folly is commonly known and accepted as an opportunity costs so employers set the expectations very low and don't ask for such things. The stupidity and incompetence are also distinguished by hiring employers during hiring and candidate selection whether they are looking for a Node.js developer or a UI developer even though its all the same language. The better pay and frequent incompetence are opportunity costs, because somebody has to write this code. The business need is present and so factors are adjusted to ensure delivery of necessary business solutions while reducing hiring risks. It made sense to hire people who could get by just writing minimal logic over a framework tool, because developers are interchangeable assets of the business that come and go rapidly in the marketplace. When there is a shortage of talent you take what you can and ensure it is commonly replaceable. It should also be stated the conditions for hiring developers were well in the developers' favor because the business need was clear and businesses could afford to hire more people while enjoying the longest running bull market in history. I suspect, though, this party is over. We now exist in a period of rapid economic contraction unlike anything in history. Before the recent bull market developers primarily existed to provide automation. The value of most developers was in the reduction of expenditure on the employer's internal operating costs. During this bull market that value became lost as the lines between automation and product creation frequently blurred. Regardless employers just knew they need people to write code and could happily afford it. COVID has put many developers out of work and economists are anticipating the economic hardships will continue for about 2 more years. From a business perspective developers are expensive cost centers. Developers do not add to the revenue of the employer. They only exist to substitute business expense for automation. The people who actually generate revenue are called something like sales, marketing, or merchandising. So, for a hiring manager of a business struggling to stay afloat why would they hire 12 barely competent people who write a few lines of code here and there for a framework SPA when instead they could hire 2 or 3 developers at a slightly hire rate that focus on automation in general? In other words the safe expectation moving forwards is to expect that developers will require more from fewer developers or will find a completely different medium with which to engage their users/clients. With many developers suddenly out of work talent is no longer rare. The opportunity costs have drastically changed in response to market pressures. The employers who will most rapidly adapt their hiring and use of developers are those under greatest financial pressure. The employers who are currently safe from market pressures, whether by their essential status or cash liquidity, will not feel this pressure and will become the new dinosaurs as they retain older and less efficient ways of shipping products.

Geeflow 6y ago

I believe this is one of those things that are really hard to understand unless you have experienced it first hand. Although I always knew how important prioritization is, I understand it way better since working on my resource-constrained side project. You often fail to appreciate just how many obviously good things you can't do because there are even more important things to do. Or, to quote Steve Jobs: "People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are."

nicbou 6y ago
It's much more obvious with side projects because there is no one else to blame. You have a complete view of the picture. I find personal projects very humbling. Even with no one stepping on my toes or setting unrealistic requirements, I still make dumb mistakes and write subpar code.

firebird84 6y ago

His statement about bigcos doesn't really jibe with mine. Bigcos are just as concerned with opportunity cost as startups, at least if they're concerned about earnings at all or are run well. You will not have headcount to attack all the problems you have at once, and you'll constantly be chasing revenue/COGS-R opportunities instead of fixing those UI glitches QA found 2 years ago that have workarounds. The day you stop chasing opportunities is the day your headcount gets taken away. It's simply not worth paying someone 6 figures to tackle those issues.

jefftk 6y ago
Startups will often have many obvious relatively simple things they're not doing. They're moving very quickly, but they have a small team and have to ruthlessly prioritize. A larger company is generally not moving as quickly, and the scale of the things that they're choosing not to do for opportunity-cost reasons gets much smaller. I worked for a money transfer startup at one point. You could use it on Android and iOS but not on desktop/web. We just hadn't gotten to it yet. If they're successful but still mobile-app only in five years, though, I'll expect that it's for reasons like "we looked into web but fraud rates were much higher" instead of it just being a matter of priorities.

JanisL 6y ago

I worked with a company last year that consistently made poor decisions due to lack of resources, especially time. Sometimes "opportunity cost" was used as an excuse for a lot of things. Now sure if you have a few different immediate options and a lack of capacity you will be forced to choose certain options and ignore others. Scarcity is a real thing and I'm not arguing otherwise. But the bit that might be classified as stupid was that very little thought was given to hiring or any form of capacity planning. As such I think just categorizing this as "opportunity cost" would be missing a very important part of the bigger picture. People can make decisions that impact the amount of resources that are available and over a longer period this is especially important. If you consistently find that you are passing up on profitable opportunities it shows that you may have a very profitable situation to hire people, if you don't pay any attention to that you risk making opportunity costs a self fulfilling prophecy.

wefarrell 6y ago
It sounds like they were focusing on the urgent at the expense of the important: https://www.eisenhower.me/eisenhower-matrix/ https://www.eisenhower.me/eisenhower-matrix/
- ghaff 6y ago
  Yes, although note in the Eisenhower matrix, you "delegate" urgent but less important tasks. If there's no one to delegate to, that falls apart a bit. Now, if you're so under-resourced that you're doing nothing but putting out fires, that's a problem. And you probably have to add resources (of whatever type including delegating to a third party), fix root causes, or decide that what you're treating as urgent really isn't.

artsyca 6y ago

Inefficiency is a form of stupidity and always being busy is a form of inefficiency

sfvisser 6y ago

I don't get the use of the terminology here. Opportunity cost is the cost associated by not reaping the benefits of an alternative not being picked. This is a cost from the perspective of the party making the choice. So in this story, 'opportunity cost' is not an explanation why something didn't happen. It is a side effect of something not happening. You could say the real opportunity cost in this story is the startup teams having a bunch of unhappy users. The explanation for the missing features is simply: they did something else. So better: "Never attribute to stupidity what is adequately explained by prioritisation"

brownbat 6y ago
Uncanny. I was also going to recommend that, maybe "ruthless prioritization," to emphasize that everyone is constantly busy and that these choices are sometimes unoptimizably hard. It would also draw a bigger distinction between the "strategic" decisions he describes at bigcos (which also involve opportunity costs!) Terminology aside, I did think he made a good point.
doodpants 6y ago
Yes, but another way of looking at it is that if you prioritize A over B, it's because the opportunity cost of not doing A would be greater than the opportunity cost of not doing B. So "prioritization" is another way of saying "minimizing opportunity cost".
- sfvisser 6y ago
  Sure, but talking about the opportunity cost of the thing you did pick feels backwards to me. Also, prioritization is not only minimizing cost, you’re probably also maximizing reward. So the calculation is more complicated anyways.
  - adrianmonk 6y ago
    I didn't see where the article talks specifically about which thing has an opportunity cost. As far as I can tell, it just says opportunity cost is the relevant phenomenon and leaves it to the reader to figure out which things have a cost and how all the math works out on that.

luckylion 6y ago

"Listen, we just had better things to do than securing our database and customer data. It's not that we don't care about the effect this leak has on the affected individuals, it's just that you can't make money by providing secure systems, so we prioritized animated emojis higher"

harimau777 6y ago

The issue that I see is that the benefits of implementing something the "stupid" way (e.g. it's faster or easier to implement) are often enjoyed by different people than those who have to bear the associated future pain.

ReactiveJelly 6y ago
Then it becomes an externality. Why should sales stop littering when development is the one cleaning up the highway?

bernulli 6y ago

This is then made even more frustrating due to the asymmetry when the opportunity cost for you for not having your problem fixed is much higher than for the person you are trying to reach. Or, more succinctly, asking `Who has the problem?' has helped me over the years to adjust my expectations, because more often than not, it is me who has the problem, and not the person I am reaching out to.

tehlike 6y ago
The part that sucks the most is when opportunity cost of not doing something is "globally" high, but the other party only optimizes locally for themselves. You will see, especially at work, when you have something that makes a ton of money, but people will be uninterested because it doesn't benefit them as much. At that point you require lots of escalations.

air7 6y ago

Wow. Well put. I'm going to use this. It feels quite true that when analyzing the behavior of any entity (and to a lesser degree, a person) it's rare to take time into account. If something wasn't done it's either stupidity, malice, or something-I-don't-understand. It's refreshing to think that it might just not have happened yet, and perhaps never will because there will always be more important things in the pipeline. So perhaps this idea is a corollary of my own pet aphorism: "Things take way, way, waaayyy longer than you'd think". Everything seems simple and easy until you set to actually do it. The kicker is that even looking back on my own work, I sometimes can't understand "What took me so long?!"

amflare 6y ago

I think the author is saying "opportunity cost" when he really means "ROI".

csours 6y ago

> "People love to conclude that something wasn't done because they are stupid, or possibly lazy. This happens about 95% of the time when you don't know a certain person/team." I used to do plant floor support in a manufacturing plant. Over the radio, people treated me like an idiot. When I walked out to the plant floor they treated me like a genius.

frandroid 6y ago

Y'all missing the most important paragraph in the whole article: > I spent many years working in a satellite office. A lot of the time when I had some deep technical disagreement about something, I'd fly to the main HQ, and go out for dinner with the other team. I wouldn't even talk about technology, just about random stuff. Once they knew me, and realize I was a human (and not a faceless blob), most technical disagreements tended to go away. People are more likely to assume positive intent and not malice/stupidity/laziness. Building relationships is important important to get bug fixed/features built. Bug prioritization isn't a just a technical nor a business exercise. Now, I want to hear which company this is that this guy could just "fly to HQ" (I'm assuming Microsoft Back in the Day) but the geographic gaps aren't always that large... :P

schnevets 6y ago
I've always believed telecommuting needs the remote equivalent of the golf course. There are certain human elements that cannot be built over a Zoom call, but do not inherently require a physical presence. I have never started a company and I was hire #76 at my current place, but if I were to start something remote, I would find a game or hobby appreciated by all the founders and make sure that remained a bedrock of our culture.
- bgilroy26 6y ago
  This is a huge opportunity. It would serve a great need to create a structured, low-pressure activity for potential business partners to participate in as they socialize over video chat. Given the potential to democratize socializing to form business partnerships, it would catch on all on its own as a way to be inclusive during the pandemic in a way that golf never was. Semi-related, I was reading a sociological research paper by Irving Crespi about playing cards in Endicott, NY and in his conclusion, he speculates that people used the structure of playing bridge or what have you in order to more easily tolerate each other's company. He was trying to explain why most card players weren't gambling seriously and I think he was right about structured activities providing a social lubricant analogous to alcohol. Perhaps the eu-social aid of structured activity is even stronger than alcohol because we're given a detailed script to play out and distract ourselves instead of simply taking the edge off of our ability to waste energy over analyzing the social situation.

bobbytherobot 6y ago

I learned a lesson about opportunity costs while worked at an IT company. When I started, the company managed the IT for small companies, most being three to five people companies. We had full control of decisions so we kept them up-to-date with the latest best practices. I'm sure there was a bias of the types of companies who went with us as we charged more than competitors. We started to gain larger clients. We thought that a 5,000 person company would be ahead of the 5 person company when it came to technology. Not so. Here is what we learned: there are political risks for changing technology. A CTO (these are not tech companies) would wait until people were complaining so extremely that people would have to feel that changes were good. It all arose from that bias most people have about change being bad unless it is ten times better.

pnutjam 6y ago
This is so true. I've been in plenty of small business that are trying to do the best and their constraints are usually based on the ability of early hires. Big companies have inertia to deal with for every change and once you get burned by something trivial that gets blamed for problems, you get very shy about improvements. I'm in the process of building a system that had to make alot of compromises based on existing expectations. It's probably a year away from being where I want it to be because every change is so slow... It's frustrating to defend these decisions every time someone comes along and notices how hard it is to use the system. I have to explain that every part of the system is broken out currently to find issues and fix them, the end goal is to stack everything together, but right now all the sausage making is on display and frankly it's appalling... (edited for readability) end goal is turning a push button system that had to be carefully monitored for breakage (while it was running after hours) into a staged system that gets checked and verified during business hours, but still fires off after hours.

heymartinadams 6y ago

Bernhardsson’s razor. Someone should make a Wikipedia entry for that.

maerF0x0 6y ago

> Never attribute to stupidity that which is adequately explained by opportunity cost "Why didn't we invest in long term issues?" (say virus research...) Because I can make lots in finance this quarter." As I understand it humans have (at least) 2 really big problems in rational thought: 1) A bias towards the short term and 2) unknown unknowns (cue Nassim Taleb) Never attribute to higher order stupidity that which can be attributed to lower order brain functions.

pnw_hazor 6y ago

In IP law, if I see terrible work product that cost my clients $5-$25K in waste, I try to be charitable and remind myself that sometimes there is context that I am not aware of that may have been the cause. Such context may be client driven immutable deadlines, client-side delays, client-side lack of communication, and so on. In reality there probably was incompetence bordering on malpractice by the prior firm that did the work. But you never know. If $100Ks (and multiple years) have been wasted, I know it is incompetence bordering on malpractice. Especially, if the firms that did the bad work have well known brands. In professions like law, medicine, or professional engineering prioritizing is important and useful but providing shoddy work product or corner cutting should be unacceptable. And often corner cutting is malpractice. In software development I used to push hard to get people to focus on getting from A to B efficiently while using an architecture that supports flexibility rather than over-engineering from the beginning. It seemed to work well. Though I did run into some managers/directors/VPs that would carefully listen to a reasonable proposal and ignore it or in one case do the opposite. I always took that as the sign to move somewhere else. Eventually leading me to go law school.

jessriedel 6y ago

So the fact that I can't filter my Amazon search by price until I choose one of multiple plausible "departments" is attributable to Amazon simply not having enough software engineers to spare for the past decade? I doubt it.

adrianmonk 6y ago

I agree, but only partly. Yes, prioritization is likely the explanation for a lot of things. It's absolutely true that the responsible team cannot do everything you'd wish. But, sometimes there's stupidity at a different level. Just because someone is making an effort at prioritization doesn't mean they are doing a good job of prioritization. It's hard to tell from the outside (where you lack the relevant knowledge), so you're kind of forced into giving them the benefit of the doubt. But sometimes that internal tools bug which they never get around to fixing is eating up 5 minutes of every employee's time every day for 2 years, and it adds up to a lot of wasted time, and they should have prioritized it but they didn't. Maybe because they didn't appreciate what the cost was, or maybe because they had some bias toward certain kinds of tasks, or maybe some other reason.

breischl 6y ago

I tend to agree with this. I do think that this article (as with most) brushes far too easily over the tension between tech debt and new features. It's not uncommon to have a product person (or even team) that spend tons of time doing analysis to find high-value features. When they show up with some slick Powerpoint/Excel thing that says "If we build this feature we make $BIGNUM", it's extremely difficult for some dev (or dev manager) to come up with an effective counterargument for working on tech debt. Partially because it's not their main job, and partially because quantifying the impact of tech debt is extremely difficult. And it's very easy for that to happen every single planning cycle, even while everyone makes appropriate noises about tech debt being super important and we're totally gonna address that but we just can't justify not going for that $BIGNUM cash first! I wish I had a solution for that - I don't. If anybody else does I'd love to hear it. :)

7532yahoogmail 6y ago

There's a lot to like in this article. I like how the author tries to remove manipulative motions (correspondingly paranoia) from the context in hopes people can see truer. Nontheless (I am 25+ years in software dev), - some 20pct of people think the office is where politics and games are played. Thus they try to play it better. That's because openness at the office is usually quite low. Such people are unmoved by push back thinking themselves the smarter, grayer haired guy. Survivors of this kind of BS actually are smart, and do have experience with effective but distorting coping skills - software should be a formal science. It's not almost all the time - the chief issue unaddressed here but smartly lead up to is the management function: as the normal scenario is that resources are vastly drwafed by problems what do we say no to? The management question when examined is complex and when it unfolds to systemic issues that are chiefly human not technical viz any of the corporate histories on quality improvement in the 80s/90s esp with company turnarounds. Ex. Detroit, Xerox, IBM under gerstner. While technical issues remain on the table, sustained under performance is ultimately rooted in management and company culture.