15 ms·

The top bug predictor is not technical, it's organizational complexity

388 points by keyP 7y ago

ChrisMarshallNY 7y ago
This is a no-brainer. As a development manager for a quarter-century, and an active software developer for a lot longer than that, I can definitely say that every place there's a "meeting of the minds" is a place for bugs. In the software itself, the more complex the design, the more of these "trouble nodes" (what I call them) there are. Each interface, each class, each data interface, is a bug farm. That's why I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software. I won't name them, because I will then get a bunch of pithy responses. These practices are often a response to the need to do Big Stuff. In order to do Big Stuff, you need a Big Team. In order to work with a Big Team, you need a Big Plan. That Big Plan needs to have delegation to all the team members; usually by giving each one a specific domain, and specifying how they will interact with each other in a Big Integration Plan. Problem is, you need this "Big" stuff. It's crazy to do without it. The way that I have found works for me, is to have an aggregate of much more sequestered small parts, each treated as a separate full product. It's a lot more work, and takes a lot more time, with a lot more overhead, but it results in a really high-quality product, and also has a great deal of resiliency and flexibility. There is no magic bullet. Software development is hard.
- jve 7y ago
  > I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software. I won't name them, because I will then get a bunch of pithy responses. Bring it on. Share your experience with youngsters. And let the elite confront with methodologies you maybe didn't have experience with.
  - ChrisMarshallNY 7y ago
    Nah, that's OK. Thanks. Just to clarify. I have been down this road. I am not interested in sacred cows or third rails. I'm trying to do all my writing and commenting, based only on my own experience and insight. I'm done with fighting on the Internet. I don't have the energy for it anymore.
    - carlmr 7y ago
      I can respect that. Although I would have liked to hear your take on it, I know what you mean.
      - ChrisMarshallNY 7y ago
        I'm always happy to chat (pontificate in an "OK Boomer" kind of way, I guess), but not in public forums. My screen name applies in a lot of places.
      - bob33212 7y ago
        Agile and Scrum can add a lot of meetings and processes and metrics into a development team. For non-technical managers this is great because they can create nice charts with story points for upper management. The above comment can devolve into a flame war because non-technical managers see Agile and Scrum in a different light. They believe that without proper management developers will be unproductive.
        carlmr 7y ago
        I can't believe I forgot this one. Scrum is so terrible, I don't know why it's still being introduced.
  - carlmr 7y ago
    I'd also be interested. Some drivers of complexity I would think of: * Using many of the GoF/OOP patterns, because you may need extensibility at some point. Basically YAGNI. * Complex, hard to mentally map, build systems (e.g. CMake). * Designing for purity over simplicity (I'm actually big on FP, here I'm thinking of the Haskell crowd which IMHO sometimes overdoes it). * Writing a complex architecture without prototyping. Often your prototype will tell you what you need. If you start architecting too much beforehand then you often waste time on some details that don't matter, and even worse, afterwards you try to force it into your architecture which doesn't actually fit the problem. The beauty of software is that it's easy to change things. Architecture on buildings is different because you need to make sure that you're not building the wrong thing. In software building the wrong thing can give you the right insights and still be faster than planning for every eventuality.
    - heisenbit 7y ago
      * Splitting requirements documents into user stories and then evolving the document further. This practice can be improved upon by adding redundancy with attaching the document to user stories and enterprise wiki. Further optimization can get to the org to CMMI level 5 but requires investment in diversity of the most critical requirements in other locations and protection of these assets from being linked.
    - doublement 7y ago
      > Writing a complex architecture without prototyping. Often your prototype will tell you what you need. One million times yes. In my experience using a prototype as an input to a specification works much better than the other way around. > Complex, hard to mentally map, build systems (e.g. CMake). Also yes. It's almost to the point where one has to understand every detail of how CMake works to get it to do one (1) specific thing you need in your build process.
- calineczka 7y ago
  > an aggregate of much more sequestered small parts, each treated as a separate full product What does it mean exactly? I feel you are trying to share a nice idea but I can't comprehend it. What are those small parts? Classes? Modules? Services? What does it mean to treat them as a separate full product within an organization?
  - winrid 7y ago
    Based on my understanding a common name would probably be Slimlane, or Blade...
  - carlmr 7y ago
    Not OP, but to me this is the Unix philosophy of having many small tools that work well and interact well. Even if your modules are very separated, if you can't individually use and play around with them they become a part of a big blob of software. Services may be products, but only if they're idependently usable. If you have a small product that's useful in and of itself (e.g. git) you can much more easily make it work well and then integrate with other good tools and replace those if necessary (e.g. if you have problems with Bitbucket/Jira/Confluence, you can switch them out for other solutions, e.g. Gitea). But if you have a huge clomplex product then at some point it becomes organizationally impossible to move away from it.
    - ChrisMarshallNY 7y ago
      Exactly.
    - nradov 7y ago
      The Unix philosophy is all well and good, but it's very limiting. There are major types of valuable software products that simply can't be built out of small tools or services.
      - ChrisMarshallNY 7y ago
        Exactly. It's just one way of doing things, and I definitely admit that some very good things have come from much more complex systems. However, bug control is absolutely vital with these systems, and you definitely need some kind of quality-assurance system, or you will be hatin' life.
- jiggawatts 7y ago
  So, just a day ago, I got dragged into a meeting where many people were involved in a discussion about the new Cloud Enterprise Application Architecture Template. Or whatever. It had a 3-tier architecture. I asked: Why? And they answered: Why not? I answered: Because layers must only be introduced if needed. Is there a need? They answered: The standard design is the need. I clarified: Is there a technical requirement? Or perhaps an organisation one, such as disparate teams working on the two components? They answered: No! Of course not! It's a unified codebase for a single app written by a single person! But it is not Enterprise enough! It must be split into layers! And then, you see, it will will match our pattern and belong. I verified the insanity: Are you saying that this finished, working application isn't currently split into layers, but you want it split into layers simply so that it can have layers? They chorused: Yes.
  - NicoJuicy 7y ago
    I actually like DDD, where code is executed per domain with a bounded context. Not for a single person though, but it will force kin developers to think more deeply. Otherwise it could easily result in a code-mesh/hell.
  - Vinnl 7y ago
    > I answered: Because layers must only be introduced if needed. Is there a need? It might have gone better if you had also stated why that is the case, e.g. "every additional layer exponentially increases the likelihood of bugs being introduced, so their introduction must be worth that risk, or the higher cost of mitigating measures". Of course, the challenge will still be that "likelihood of bugs" is rather abstract, and often people believe they can be prevented just by paying more attention, and assume that that will happen of its own accord.
  - organsnyder 7y ago
    I did a project like that at my old job. It was a single screen with a single purpose (login the user via oauth SSO, then collect a couple of pieces of input and submit them to a backend webservice), so it was assigned to me rather than creating a project team. To make it match the rest of our application architecture I created a REST layer in C# that communicated via SOAP to an ESB that forwarded the SOAP request to a Java webservice that finally forwarded it to the backend system. I did depart from our organizational norm by doing the frontend with plain HTML+JS (plus Boostrap, IIRC) rather than AngularJS. Yes, it was complicated, but I think there is a benefit: it's very clear where certain functionality should live. The C# REST layer was application-facing, so it took care of SSO and basic validation. The Java webservice contained the business logic to validate things from an broader enterprise perspective. The ESB was a piece of trash that did provide authnz so the Java webservice didn't have to. Was it worth the complexity? Probably not, in this case. But those sorts of applications tend to have long lifespans and evolving requirements, so the standardization can be helpful.
- andydavieswork 7y ago
  > In order to do Big Stuff, you need a Big Team. Depends on your definition of Big Stuff. If you mean send a rocket to Mars, then yes. But the vast majority of us are working on simple web apps that might call a few apis, yet these seem to require Big Teams. Compare that to what a single game developer might produce, and compare the complexity and performance of the product. I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention. Getting things done in these paradigms takes _forever_, so you need a Big Team.
  - ChrisMarshallNY 7y ago
    That's true. Like I said, I can only speak from my experience. I do think that we are in a sort of "dependency hell," that is sorting itself out. In the end, a few really good dependencies will still be standing in the blasted wasteland. Dependencies mean that a small team can do Big Stuff, but that relies on the dependency being good. "Good" means a lot of things. Low bug count is one metric, but so is clear documentation, community support, developer support, and even tribal knowledge. It doesn't necessarily mean "buzzword-compliant," but sometimes aligning to modern "buzz" means that it benefits from the tribal knowledge that exists for that term, and you can deprecate some things like documentation and training. People often think that I'm a dependency curmudgeon. I'm not. I am, however, a dependency skeptic. I will rely on operating system frameworks and utilities almost without question, but I won't just add any old data processor to my project because it's "cool." I need to be convinced that it has good quality, good support, and a high "bus coefficient," not to mention that it meets my needs, and doesn't introduce a lot of extra overhead. Nothing sucks more than building a system, based on a subsystem that disintegrates a year down the road. I suspect many folks that have built systems based on various Google tech, can relate. I have had that experience with Apple tech, over the years (Can you say "OpenDoc"? I knew you could!).
  - chiefalchemist 7y ago
    > I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention. Perhaps. But what I've also seen is the head count of a given project is a direct reflection of the intra-org status of the person heading the project. There's a belief - that's a myth - that if 3 ppl is good the 6 is twice as good and time will be cut in half. I think we also know - with rare exception - that productivity slides as heads increase. That's a given. Then there's also a belief - again a myth - that some mod dev practices can fix the increased head count issue. It might mitigate it here and there. But MDP can only do so much to fix a dysfunctional org/group. Ultimately it's a leadership/management issue. Process and technology are too often lipstick on a pig.
- the_af 7y ago
  > That's why I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software Maybe I'm nitpicking, but the article points out the number #1 predictor of software bugs is not the complexity of software but of the organization itself. A single person can make an hugely complex piece of software, and a relatively large team can make a conceptually simple system. As for software complexity itself, there's an interesting research result that the thing that matters the most is line count. Not cyclomatic complexity, not the type system, not modularity or test coverage, not the programming language -- looking at the line count alone trumped all the other metrics in predicting flaws. (I can't look for this paper now, but I'm sure with a bit of googling anyone can).
  - ChrisMarshallNY 7y ago
    That makes sense. Every line is a potential bug. But it's not the only factor, and, quite frequently, it's a matter of correlation, as opposed to causation. That kind of thing can be very tricky to determine. When I write software, my first stab at a function tends to be a fairly linear, high-LoC solution, which I then refactor in stages; reducing LoC each time, and ensuring that the quality level remains consistent, or improves. As far as quality goes, my first, naive stab, was just fine, and I have actually introduced bugs during my refactoring reduction.
    - the_af 7y ago
      Note that I'm not arguing about underlying reasons, just saying what the empirical results show. That's reality. So if you try to predict software bugs using modularization (or lack thereof) or "if-then-else" branches, or whatever complexity metric you can think of, you'll get one result. If you try to predict them using simple line count, you'll get another result. The second one will have better precision & recall. So no metric so far has been shown to be better than simply counting lines. That's not an obvious result, but it's the truth. Sadly, you'll have to believe me because I cannot find the studies right now.
      - shantly 7y ago
- pjc50 7y ago
  In order to get Big VC Money, before doing a Big IPO, you need a Big Team doing a Big Plan. Nobody's going to give you a billion dollars for something that's simple enough for one person to do. You may say, "but this problem doesn't need a billion dollars!", to which I say "your corporate ownership structure isn't complicated enough, you need to make sure that as much of the billion dollars sticks to your hands as possible after you fail". WeWork passim.
  - bob33212 7y ago
    I interviewed at a well funded company for engineering manager. The interview centered around how they were going to build a 100 person team so the job would include lots of interviewing and hiring. I assume that some investor was told that "We are going to have 100 developers while our competitor has only 20" and the investor bought into that plan.
  - deleted 7y ago
    [deleted]
  - blowski 7y ago
    Plus managers who define their worth by easily measurable values like how many 0s on their p+l statement, and lines to them on the org-chart. Success of the project is much more subjective.
- Meai 7y ago
  I've started to see it that way too. Every place where there is source code, the complexity grows instantly - it's like a virus. The only firewall you can have for this is if you have it all in different projects that need to justify themselves on their own on all merits, financially, technically, etc.
- afarrell 7y ago
  > This is a no-brainer. It is NOT obvious to someone who hasn't thought about it for a while. Suppose someone is trying to persuade another person and just assumes that they already realize the costs of organisational complexity. There's a good chance they'll run into a wall and not get the message across. If you think realizing it is a no-brainer, then your 25 years of experience is showing.
  - ZainRiz 7y ago
    There's a name for the bias where something seems obvious once you've been told about it, but I can't remember what it's called (I don't think it's hindsight bias...)
    - afarrell 7y ago
      Egg of Columbus?
- streetcat1 7y ago
  You might be ignoring the productivity gains in software dev over the last 10 years. With open-source, languages like go/rust, excellent IDEs and basically free compute, the amount that a single developer can produce is 10x/20x more.
  - ChrisMarshallNY 7y ago
    Tell me about it. I write in Swift. I love it. I started with Machine Code (not ASM -Machine Code). Also, all those lovely system frameworks are wonderful. I used to use MacApp (Google it), and PowerPlant (Same). AppKit and UIKit knock them into a cocked hat. SwiftUI shows promise, but it may be a year or two before it can really match the standards.
  - abraxas 7y ago
    This is pure hogwash. All that productivity and more has been available for two decades with Java and C#. It's just that hipsters rejected it wholesale because those are their parents' programming languages.
- 0x445442 7y ago
  I agree with everything you have said. But the trends in "The Enterprise" are to eschew these ideas in favor of overly complex serverless architectures with poorly specified interfaces where any pluggable developer/resource can perform hit and runs on any component. What I've seen this lead to is the most brittle, bug ridden, low quality software in my career. And the irony is it's led to none of the perceived benefits of serverless architectures but has enhanced all the drawbacks of monolith architectures. My best guess is to why things have become this way is that middle management in "The Enterprised" reckoned "Agile" as an opportunity to commoditize software development.
- downerending 7y ago
  > Problem is, you need this "Big" stuff. It's crazy to do without it. Sometimes you do. But many times big stuff gets written for reasons other than need. One of the best wins in our industry is to recognize that the big stuff isn't needed and to never start the project in the first place.
thenewnewguy 7y ago
Just skimmed over the post, so it's possible they pointed this out and I didn't notice - but I think this is misleading. The title makes it sound like organizational complexity _causes_ bugs, but in reality I think both are simply effects of a more underlying cause. Larger and more complicated software both requires a bigger team (therefore more organizational complexity) and is more likely to contain bugs.
- artsyca 7y ago
  Conway's principle
- augustl 7y ago
  I think that's a fair point. But organizational complexity is compared to other measures, such as the complexity of the software itself, the number of dependencies, etc - i.e. the size of the software itself - and the study found that organizational complexity is still the #1 method.
- kitd 7y ago
  Steve McConnell identified it as the number of lines of communication in the team or dept creating the module, incl dependents and dependers. It's why Conway's Law exists, and points towards the importance of well-designed and -specified APIs.
  - ChrisMarshallNY 7y ago
    Upvote for mentioning Steve McConnell.
  - daveslash 7y ago
    If you consider people on a team as nodes in a graph, and lines of communication as edges, then a team of n people has potentially (n(n-1))/2 potential lines of communication. I try to express to people that the more potential lines of communication you have, the greater the chance of miscommunication. I think this is also called out in Brooks' The Mythical Man Month.
he0001 7y ago
Isn’t this aligned with Conway’s law? I mean, a complex business model requires, most likely or eventually, a complex solution? If not, the two systems are at odds, and the computer system is even more complex/buggy since it doesn’t follow the organization's complexity, it doesn’t do what the organization need it to do. That at least is my experience anyway.
- tekmaven 7y ago
  I was surprised that Conway's law was not mentioned.
  - MontyCarloHall 7y ago
    In the original publication that’s the subject of the article, it was: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
wycy 7y ago
The article examines this through the lens of Windows Vista. Am I the only person who actually did like Vista and didn't have any problems with it? I gathered that most of the issues people had with it was caused by third party incompatible software and hardware.
- finnjohnsen2 7y ago
  No. It was Windows Longhorn. Microsoft abandoned it.
- kryptiskt 7y ago
  I also had little trouble with Vista and liked it well enough. But I had plenty of RAM, I believe it performed badly with 1 GB or less. And of course people got hung up on UAC.
  - swiley 7y ago
    That’s kind of crazy. Firefox and libreoffice don’t do well in 1 Gig of ram but at least they’re doing something. You can run a decent DE and few decent apps in 1gig just fine with most Linux distros.
    - barrkel 7y ago
      And Microsoft Word ran perfectly well on 16MB of RAM in Windows 95, back in the day; and even better on NT with 32 or 64MB, productive and more than comfy. I guess my point is that running decent software on what today would be considered very little hardware is a solved problem, but it's not what the economy is optimized for.
      - swiley 7y ago
        The difference here is that LibreOffice is still maintained (in fact, the math typesetting in Microsoft office is practically unmaintained at this point and is just miserable to use.) Old windows (and old Linux) have serious problems that modern OSes don’t have. You can run modern good and compatible software in very little ram and the only reason not to is because someone else is forcing you or you’re just not aware.
amelius 7y ago
From the article: > In the replicated study the predictive value of organizational structure is not as high. Out of 4 measured models, it gets the 2nd highest precision and the 3rd highest recall.
nelsonic 7y ago
Does this mean that a solo developer working on a SaaS product can avoid bugs?
- augustl 7y ago
  That's actually very interesting IMO! Now that you said that, it seems obvious to me that there's a sweet spot somewhere, and that it's higher than 1 and (probably much) lower than 100.
- donkeyd 7y ago
  Well, in theory anyone can avoid bugs. It's just really costly and requires a very structured approach to doing anything. It's very unlikely, however, that you figure out every single combination of variables while writing tests. So, so in practice, I don't think it's possible to avoid bugs, unless you have a really tiny code base, maybe.
- _ZeD_ 7y ago
  surely this solo developer will avoid bugs regarding "communication misunderstanding" between the team elements.
  - AnimalMuppet 7y ago
    I'm not totally sure about that. "Me, yesterday" has to communicate with "me, today", and communication misunderstandings can absolutely happen. Now, sure, such things happen less when it's me talking to me than when it's me talking to you. They still happen, though.
- dredmorbius 7y ago
  Days of yore when Bill Joy would rewrite / update Unix and userland over the weekend. https://invidio.us/watch?v=08PmIv1l5LY https://invidio.us/watch?v=08PmIv1l5LY
sorokod 7y ago
Conway's law strikes again.
chiefalchemist 7y ago
Code/technology is nothing more than a tool. A toolbox is only as good as the person/peoples who pick it up. That is a great tool will not save a disorganized organization. The great tool will not make a crap product better. Blaming the means for the ends is a classic n00b mistake. A mistake that's being made over and over and over again.
MontyCarloHall 7y ago
Looking at the metrics used in the publication[0], it seems most of them focus on the absolute number of engineers working on a given component. This makes sense — more engineers touching a component introduces more opportunities for bugs. (Edit: as other commenters have pointed out, total lines of code, highly correlated to number of engineers, is likely the best first-order predictor of bugginess.) I bet we can improve predictive power by considering the degree of overengineering, i.e., the number of engineers working on a task (edit: or lines of code) relative to the complexity of the task they’re working on. 100 people working on a task that could be accomplished by a single person will result in a much buggier product than 100 people working on a task that actually requires 100 people. The complexity of code expands to fill available engineering capacity, regardless of how simple the underlying task is; put 100 people to work on FizzBuzz and you’ll get a FizzBuzz with the complexity of a 100 person project[1]. Unnecessary complexity results in buggier code than necessary complexity because unnecessary components have inherently unclear roles. Edit: substitute "100 people" with "10 million lines of code" and "1 person" with "1000 lines of code" and my statement should still hold true. [0] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- augustl 7y ago
  That's super interesting! What would be a good way to measure the comlexity of a task in some objective way? Also, the study doesn't really take "tasks" into account at all, it seems. Just modules and data relating to the modules.
  - MontyCarloHall 7y ago
    >What would be a good way to measure the comlexity of a task in some objective way? From an existing codebase this would be very difficult to objectively assess. I think you’d have to study it empirically — come up with a set of tasks (“A”) that each takes a single programmer “P” on average a week to complete. Then come up with a set of tasks (“B”) that each takes a team “T” of 10 programmers on average a week to complete (ensure that 10 programmers is a lower bound, i.e. decreasing the number of coders causes the project to take longer). Across multiple solo programmers and teams, compare the quality of the code produced by programmers P on tasks A, teams T on tasks B, and teams T on tasks A. I’d bet P/A > T/B > T/A.
hos234 7y ago
Herbert Simon is who you read first when you thinking about orgs - https://en.m.wikipedia.org/wiki/Satisficing https://en.m.wikipedia.org/wiki/Satisficing That will take to you to healthy and productive places.
ChrisSD 7y ago
Previous discussion (which got flagged): https://news.ycombinator.com/item?id=21795462 https://news.ycombinator.com/item?id=21795462
- tyingq 7y ago
  I can't quickly tell why it was flagged. Was the study highly flawed? Or promoted in a dishonest way? Or was it really the comments as a whole that got it flagged?
  - augustl 7y ago
    Probably because the title was originally extremely linkbait-y.
Merrill 7y ago
>Organizational Complexity. Measures number of developers workong on the module, number of ex-developers that used to work on the module but no longer does, how big a fraction of the organization as a whole that works or has worked on the module, the distance in the organization between the developer and the decision maker, etc. After one of the early big software project failures (maybe Multics?) there was a quote about software projects going around (maybe John R Pierce?) that "If it can't be done by two people in six months, it can't be done." One of the functions of good software design is to break the system down into pieces that a couple of people can complete in a reasonable length of time.
mirekrusin 7y ago
...which is likely proxy for complexity of the task - the more difficult the task, the more likely it'll have bugs - not an exciting revelation. Their "code complexity" means nothing. If you compare simple "todo web app" it'll have orders of magnitude more "code complexity" than, for example, sha256 hash implementation.
- TheCoelacanth 7y ago
  And rightly so. It is much easier to write a bug-free sha256 implementation than try to write a bug-free To-Do app.
kozak 7y ago
I have a Microsoft keyboard that has a dedicated Calculator button. In older versions of Windows, I used to press that button and start entering numbers right away. But in newer updates of Windows 10, I now have to press the Calculator button, WAIT FOR THE CALCULATOR TO LOAD, and then start typing my digits. I think this is ridiculous.
- redleader9345 7y ago
  Agreed. The market for super snappy user experience seems to be underserved. Maybe not enough demand? Or maybe a symptom of the "everything is free and paid for with advertising" model we have today.
- chapium 7y ago
  I don't share this experience. I think you have an underlying issue.
  - kozak 7y ago
    This started happening when default calculator changed from a classic native app to the new "modern" app.
- contextfree 7y ago
  The calculator team has a GitHub discussion issue open tracking launch performance investigations if you're interested: https://github.com/microsoft/calculator/issues/209 https://github.com/microsoft/calculator/issues/209
- contingencies 7y ago
  If you were using Linux, solving your problem would be trivial. Practically, I can only recommend using a non-local calculator such as a search engine, since despite network latency that codepath is more heavily optimized and people now spend so much time in browsers. CTRL+L (address bar) then type "100+50/25=" and press enter. Bingo.
kabes 7y ago
The article ends with a mention of the book 'Accellerate'. Accellerate is your typical management book, based on some surveys with bad statistics and worse conclusions. Weird he mentions this book after talking about what a proper, replicated study Microsoft Research did.
zubairq 7y ago
I guess this is why startups exist because it it almost impossible for larger firms to execute good ideas even if they think of the idea themselves
- moretai 7y ago
  What is the underlying reason goliaths don't execute ideas well? Too many chefs in the kitchen?
  - jgust 7y ago
    Political land grabs for the "new hotness".
  - gfs78 7y ago
    Lots of freeloaders and incompetent power trippers in the middle layers and above. Small orgs. and startups cannot afford this kind of workers. In my current project (big co.) we have a technical PM, a non-technical PM, a non programmer dev lead, an scrum master and a lead business analyst, all involved in managing the work of a team of 2 and a half (a sr ba/qa guy, a part-time ssr dev and me). Waste work is probably in the 90%.
    - spookthesunset 7y ago
      > Lots of freeloaders and incompetent power trippers in the middle layers and above. Not just middle layers and up. Freeloaders and gatekeepers everywhere.
  - hnick 7y ago
    In my experience it's risk aversion. They're more worried about losing out from doing the wrong thing or breaking what they have, than a slow death from decaying market relevance. It's much easier to stay the course than to stick your neck out asking to change things.
- asdfman123 7y ago
  I don't think that's true, but often times when you work in a large org building actually ANYTHING is like pulling teeth. Every decision you make is second guessed by 8 other people, and anything you do impacts 5 other teams. It's infuriating unless you're the type of person who loves working through people problems, and a lot of developers, including myself, aren't that kind of person. Also, maybe it has to do with the fact that failure is an expected part of startups, but in the business world there's perverse incentives to build something mediocre, expensive and ultimately useless just to give the appearance of success. With a startup, you're free to do whatever the hell you want. If it works, it works, and if it doesn't it doesn't. I guess it would be possible to give in-house teams free reign to try out new ideas without all the organizational friction, but the startup model works, so why not just throw some money at some kids and see what happens?
johnwatson11218 7y ago
The use of the term 'p-value' seems off, it looks like he is referring to a different concept but using an overloaded term.
habosa 7y ago
This rings true for anyone who has ever worked at a big tech company (I work at Google). At Google when your project begins to scale up you can ask for more money, more people, or both. Most teams ask for both. What you can't ask for is different people. You can't solve your distributed systems problems by adding 5 more mid-level software engineers to your team who have not worked in the domain. Yet due to how hiring works, this is what's offered to you unless you want to do the recruiting yourself. Google views all software engineers as interchangeable at their level. I have seen people being sent to work on an Android app with hundreds of millions of users despite never having done mobile development before. That normally goes about as well as you'd expect. So you end up with teams of 20 people slowly doing work that could be done quickly by 5 experts. In some cases all you lose is speed. In other cases this is fatal. Some things simply cannot be done without the right team.
- natalyarostova 7y ago
  I see the same thing, and the only way I can reconcile this is that the benefit to sr leadership in terms of treating SDEs as fungible is so massive that it is still worth the massive productivity loss from assuming exchangability.
  - amznthrowaway5 7y ago
    What are the benefits to treating SDEs as fungible? At Amazon, Sr. Leadership and HR love to pretend all SDEs at a given level are interchangeable, level actually indicates competence, and leetcoding external hires with zero domain knowledge have far more worth than internal promos. All of the above assumptions seem completely insane to me and have resulted in the destruction of many projects.
    - natalyarostova 7y ago
      Yeah me too. Also at amazon. And yet amazon is obscenely successful, as are other big tech companies which take similar strategies. It seems that matching expertise to projects is so fucking hard that just giving up at the start and accepting it’s impossible is the optimal strategy. Honestly I don’t know. I agree it’s weird. But these companies keep succeeding doing it this way, so I’m not sure what to make of it.
neilobremski 7y ago
I think all current and ex Microsoftees can agree (and probably other workers in Big Tech Corp) that this is not only obvious but ongoing and dastardly resilient to getting solved! At some level this must be a sociological thing because humans seem to be hardwired into repeating this mistake. This happens at smaller companies in smaller ways but the effect is the same. It's worse than the "Mythical Man Month" in that production is not simply slowed down but it is slowly made rotten until it gets burned, buried, or passed off to out-sourced maintenance.

388 points by keyP 7y ago

This is a no-brainer. As a development manager for a quarter-century, and an active software developer for a lot longer than that, I can definitely say that every place there's a "meeting of the minds" is a place for bugs. In the software itself, the more complex the design, the more of these "trouble nodes" (what I call them) there are. Each interface, each class, each data interface, is a bug farm. That's why I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software. I won't name them, because I will then get a bunch of pithy responses. These practices are often a response to the need to do Big Stuff. In order to do Big Stuff, you need a Big Team. In order to work with a Big Team, you need a Big Plan. That Big Plan needs to have delegation to all the team members; usually by giving each one a specific domain, and specifying how they will interact with each other in a Big Integration Plan. Problem is, you need this "Big" stuff. It's crazy to do without it. The way that I have found works for me, is to have an aggregate of much more sequestered small parts, each treated as a separate full product. It's a lot more work, and takes a lot more time, with a lot more overhead, but it results in a really high-quality product, and also has a great deal of resiliency and flexibility. There is no magic bullet. Software development is hard.

jve 7y ago
> I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software. I won't name them, because I will then get a bunch of pithy responses. Bring it on. Share your experience with youngsters. And let the elite confront with methodologies you maybe didn't have experience with.
- ChrisMarshallNY 7y ago
  Nah, that's OK. Thanks. Just to clarify. I have been down this road. I am not interested in sacred cows or third rails. I'm trying to do all my writing and commenting, based only on my own experience and insight. I'm done with fighting on the Internet. I don't have the energy for it anymore.
  - carlmr 7y ago
    I can respect that. Although I would have liked to hear your take on it, I know what you mean.
    - ChrisMarshallNY 7y ago
      I'm always happy to chat (pontificate in an "OK Boomer" kind of way, I guess), but not in public forums. My screen name applies in a lot of places.
    - bob33212 7y ago
      Agile and Scrum can add a lot of meetings and processes and metrics into a development team. For non-technical managers this is great because they can create nice charts with story points for upper management. The above comment can devolve into a flame war because non-technical managers see Agile and Scrum in a different light. They believe that without proper management developers will be unproductive.
      - carlmr 7y ago
        I can't believe I forgot this one. Scrum is so terrible, I don't know why it's still being introduced.
- carlmr 7y ago
  I'd also be interested. Some drivers of complexity I would think of: * Using many of the GoF/OOP patterns, because you may need extensibility at some point. Basically YAGNI. * Complex, hard to mentally map, build systems (e.g. CMake). * Designing for purity over simplicity (I'm actually big on FP, here I'm thinking of the Haskell crowd which IMHO sometimes overdoes it). * Writing a complex architecture without prototyping. Often your prototype will tell you what you need. If you start architecting too much beforehand then you often waste time on some details that don't matter, and even worse, afterwards you try to force it into your architecture which doesn't actually fit the problem. The beauty of software is that it's easy to change things. Architecture on buildings is different because you need to make sure that you're not building the wrong thing. In software building the wrong thing can give you the right insights and still be faster than planning for every eventuality.
  - heisenbit 7y ago
    * Splitting requirements documents into user stories and then evolving the document further. This practice can be improved upon by adding redundancy with attaching the document to user stories and enterprise wiki. Further optimization can get to the org to CMMI level 5 but requires investment in diversity of the most critical requirements in other locations and protection of these assets from being linked.
  - doublement 7y ago
    > Writing a complex architecture without prototyping. Often your prototype will tell you what you need. One million times yes. In my experience using a prototype as an input to a specification works much better than the other way around. > Complex, hard to mentally map, build systems (e.g. CMake). Also yes. It's almost to the point where one has to understand every detail of how CMake works to get it to do one (1) specific thing you need in your build process.
calineczka 7y ago
> an aggregate of much more sequestered small parts, each treated as a separate full product What does it mean exactly? I feel you are trying to share a nice idea but I can't comprehend it. What are those small parts? Classes? Modules? Services? What does it mean to treat them as a separate full product within an organization?
- winrid 7y ago
  Based on my understanding a common name would probably be Slimlane, or Blade...
- carlmr 7y ago
  Not OP, but to me this is the Unix philosophy of having many small tools that work well and interact well. Even if your modules are very separated, if you can't individually use and play around with them they become a part of a big blob of software. Services may be products, but only if they're idependently usable. If you have a small product that's useful in and of itself (e.g. git) you can much more easily make it work well and then integrate with other good tools and replace those if necessary (e.g. if you have problems with Bitbucket/Jira/Confluence, you can switch them out for other solutions, e.g. Gitea). But if you have a huge clomplex product then at some point it becomes organizationally impossible to move away from it.
  - ChrisMarshallNY 7y ago
    Exactly.
  - nradov 7y ago
    The Unix philosophy is all well and good, but it's very limiting. There are major types of valuable software products that simply can't be built out of small tools or services.
    - ChrisMarshallNY 7y ago
      Exactly. It's just one way of doing things, and I definitely admit that some very good things have come from much more complex systems. However, bug control is absolutely vital with these systems, and you definitely need some kind of quality-assurance system, or you will be hatin' life.
jiggawatts 7y ago
So, just a day ago, I got dragged into a meeting where many people were involved in a discussion about the new Cloud Enterprise Application Architecture Template. Or whatever. It had a 3-tier architecture. I asked: Why? And they answered: Why not? I answered: Because layers must only be introduced if needed. Is there a need? They answered: The standard design is the need. I clarified: Is there a technical requirement? Or perhaps an organisation one, such as disparate teams working on the two components? They answered: No! Of course not! It's a unified codebase for a single app written by a single person! But it is not Enterprise enough! It must be split into layers! And then, you see, it will will match our pattern and belong. I verified the insanity: Are you saying that this finished, working application isn't currently split into layers, but you want it split into layers simply so that it can have layers? They chorused: Yes.
- NicoJuicy 7y ago
  I actually like DDD, where code is executed per domain with a bounded context. Not for a single person though, but it will force kin developers to think more deeply. Otherwise it could easily result in a code-mesh/hell.
- Vinnl 7y ago
  > I answered: Because layers must only be introduced if needed. Is there a need? It might have gone better if you had also stated why that is the case, e.g. "every additional layer exponentially increases the likelihood of bugs being introduced, so their introduction must be worth that risk, or the higher cost of mitigating measures". Of course, the challenge will still be that "likelihood of bugs" is rather abstract, and often people believe they can be prevented just by paying more attention, and assume that that will happen of its own accord.
- organsnyder 7y ago
  I did a project like that at my old job. It was a single screen with a single purpose (login the user via oauth SSO, then collect a couple of pieces of input and submit them to a backend webservice), so it was assigned to me rather than creating a project team. To make it match the rest of our application architecture I created a REST layer in C# that communicated via SOAP to an ESB that forwarded the SOAP request to a Java webservice that finally forwarded it to the backend system. I did depart from our organizational norm by doing the frontend with plain HTML+JS (plus Boostrap, IIRC) rather than AngularJS. Yes, it was complicated, but I think there is a benefit: it's very clear where certain functionality should live. The C# REST layer was application-facing, so it took care of SSO and basic validation. The Java webservice contained the business logic to validate things from an broader enterprise perspective. The ESB was a piece of trash that did provide authnz so the Java webservice didn't have to. Was it worth the complexity? Probably not, in this case. But those sorts of applications tend to have long lifespans and evolving requirements, so the standardization can be helpful.
andydavieswork 7y ago
> In order to do Big Stuff, you need a Big Team. Depends on your definition of Big Stuff. If you mean send a rocket to Mars, then yes. But the vast majority of us are working on simple web apps that might call a few apis, yet these seem to require Big Teams. Compare that to what a single game developer might produce, and compare the complexity and performance of the product. I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention. Getting things done in these paradigms takes _forever_, so you need a Big Team.
- ChrisMarshallNY 7y ago
  That's true. Like I said, I can only speak from my experience. I do think that we are in a sort of "dependency hell," that is sorting itself out. In the end, a few really good dependencies will still be standing in the blasted wasteland. Dependencies mean that a small team can do Big Stuff, but that relies on the dependency being good. "Good" means a lot of things. Low bug count is one metric, but so is clear documentation, community support, developer support, and even tribal knowledge. It doesn't necessarily mean "buzzword-compliant," but sometimes aligning to modern "buzz" means that it benefits from the tribal knowledge that exists for that term, and you can deprecate some things like documentation and training. People often think that I'm a dependency curmudgeon. I'm not. I am, however, a dependency skeptic. I will rely on operating system frameworks and utilities almost without question, but I won't just add any old data processor to my project because it's "cool." I need to be convinced that it has good quality, good support, and a high "bus coefficient," not to mention that it meets my needs, and doesn't introduce a lot of extra overhead. Nothing sucks more than building a system, based on a subsystem that disintegrates a year down the road. I suspect many folks that have built systems based on various Google tech, can relate. I have had that experience with Apple tech, over the years (Can you say "OpenDoc"? I knew you could!).
- chiefalchemist 7y ago
  > I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention. Perhaps. But what I've also seen is the head count of a given project is a direct reflection of the intra-org status of the person heading the project. There's a belief - that's a myth - that if 3 ppl is good the 6 is twice as good and time will be cut in half. I think we also know - with rare exception - that productivity slides as heads increase. That's a given. Then there's also a belief - again a myth - that some mod dev practices can fix the increased head count issue. It might mitigate it here and there. But MDP can only do so much to fix a dysfunctional org/group. Ultimately it's a leadership/management issue. Process and technology are too often lipstick on a pig.
the_af 7y ago
> That's why I'm a skeptic of a number of modern development practices that deliberately increase the complexity of software Maybe I'm nitpicking, but the article points out the number #1 predictor of software bugs is not the complexity of software but of the organization itself. A single person can make an hugely complex piece of software, and a relatively large team can make a conceptually simple system. As for software complexity itself, there's an interesting research result that the thing that matters the most is line count. Not cyclomatic complexity, not the type system, not modularity or test coverage, not the programming language -- looking at the line count alone trumped all the other metrics in predicting flaws. (I can't look for this paper now, but I'm sure with a bit of googling anyone can).
- ChrisMarshallNY 7y ago
  That makes sense. Every line is a potential bug. But it's not the only factor, and, quite frequently, it's a matter of correlation, as opposed to causation. That kind of thing can be very tricky to determine. When I write software, my first stab at a function tends to be a fairly linear, high-LoC solution, which I then refactor in stages; reducing LoC each time, and ensuring that the quality level remains consistent, or improves. As far as quality goes, my first, naive stab, was just fine, and I have actually introduced bugs during my refactoring reduction.
  - the_af 7y ago
    Note that I'm not arguing about underlying reasons, just saying what the empirical results show. That's reality. So if you try to predict software bugs using modularization (or lack thereof) or "if-then-else" branches, or whatever complexity metric you can think of, you'll get one result. If you try to predict them using simple line count, you'll get another result. The second one will have better precision & recall. So no metric so far has been shown to be better than simply counting lines. That's not an obvious result, but it's the truth. Sadly, you'll have to believe me because I cannot find the studies right now.
    - shantly 7y ago
pjc50 7y ago
In order to get Big VC Money, before doing a Big IPO, you need a Big Team doing a Big Plan. Nobody's going to give you a billion dollars for something that's simple enough for one person to do. You may say, "but this problem doesn't need a billion dollars!", to which I say "your corporate ownership structure isn't complicated enough, you need to make sure that as much of the billion dollars sticks to your hands as possible after you fail". WeWork passim.
- bob33212 7y ago
  I interviewed at a well funded company for engineering manager. The interview centered around how they were going to build a 100 person team so the job would include lots of interviewing and hiring. I assume that some investor was told that "We are going to have 100 developers while our competitor has only 20" and the investor bought into that plan.
- deleted 7y ago
  [deleted]
- blowski 7y ago
  Plus managers who define their worth by easily measurable values like how many 0s on their p+l statement, and lines to them on the org-chart. Success of the project is much more subjective.
Meai 7y ago
I've started to see it that way too. Every place where there is source code, the complexity grows instantly - it's like a virus. The only firewall you can have for this is if you have it all in different projects that need to justify themselves on their own on all merits, financially, technically, etc.
afarrell 7y ago
> This is a no-brainer. It is NOT obvious to someone who hasn't thought about it for a while. Suppose someone is trying to persuade another person and just assumes that they already realize the costs of organisational complexity. There's a good chance they'll run into a wall and not get the message across. If you think realizing it is a no-brainer, then your 25 years of experience is showing.
- ZainRiz 7y ago
  There's a name for the bias where something seems obvious once you've been told about it, but I can't remember what it's called (I don't think it's hindsight bias...)
  - afarrell 7y ago
    Egg of Columbus?
streetcat1 7y ago
You might be ignoring the productivity gains in software dev over the last 10 years. With open-source, languages like go/rust, excellent IDEs and basically free compute, the amount that a single developer can produce is 10x/20x more.
- ChrisMarshallNY 7y ago
  Tell me about it. I write in Swift. I love it. I started with Machine Code (not ASM -Machine Code). Also, all those lovely system frameworks are wonderful. I used to use MacApp (Google it), and PowerPlant (Same). AppKit and UIKit knock them into a cocked hat. SwiftUI shows promise, but it may be a year or two before it can really match the standards.
- abraxas 7y ago
  This is pure hogwash. All that productivity and more has been available for two decades with Java and C#. It's just that hipsters rejected it wholesale because those are their parents' programming languages.
0x445442 7y ago
I agree with everything you have said. But the trends in "The Enterprise" are to eschew these ideas in favor of overly complex serverless architectures with poorly specified interfaces where any pluggable developer/resource can perform hit and runs on any component. What I've seen this lead to is the most brittle, bug ridden, low quality software in my career. And the irony is it's led to none of the perceived benefits of serverless architectures but has enhanced all the drawbacks of monolith architectures. My best guess is to why things have become this way is that middle management in "The Enterprised" reckoned "Agile" as an opportunity to commoditize software development.
downerending 7y ago
> Problem is, you need this "Big" stuff. It's crazy to do without it. Sometimes you do. But many times big stuff gets written for reasons other than need. One of the best wins in our industry is to recognize that the big stuff isn't needed and to never start the project in the first place.

thenewnewguy 7y ago

Just skimmed over the post, so it's possible they pointed this out and I didn't notice - but I think this is misleading. The title makes it sound like organizational complexity _causes_ bugs, but in reality I think both are simply effects of a more underlying cause. Larger and more complicated software both requires a bigger team (therefore more organizational complexity) and is more likely to contain bugs.

artsyca 7y ago
Conway's principle
augustl 7y ago
I think that's a fair point. But organizational complexity is compared to other measures, such as the complexity of the software itself, the number of dependencies, etc - i.e. the size of the software itself - and the study found that organizational complexity is still the #1 method.
kitd 7y ago
Steve McConnell identified it as the number of lines of communication in the team or dept creating the module, incl dependents and dependers. It's why Conway's Law exists, and points towards the importance of well-designed and -specified APIs.
- ChrisMarshallNY 7y ago
  Upvote for mentioning Steve McConnell.
- daveslash 7y ago
  If you consider people on a team as nodes in a graph, and lines of communication as edges, then a team of n people has potentially (n(n-1))/2 potential lines of communication. I try to express to people that the more potential lines of communication you have, the greater the chance of miscommunication. I think this is also called out in Brooks' The Mythical Man Month.

he0001 7y ago

Isn’t this aligned with Conway’s law? I mean, a complex business model requires, most likely or eventually, a complex solution? If not, the two systems are at odds, and the computer system is even more complex/buggy since it doesn’t follow the organization's complexity, it doesn’t do what the organization need it to do. That at least is my experience anyway.

tekmaven 7y ago
I was surprised that Conway's law was not mentioned.
- MontyCarloHall 7y ago
  In the original publication that’s the subject of the article, it was: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

wycy 7y ago

The article examines this through the lens of Windows Vista. Am I the only person who actually did like Vista and didn't have any problems with it? I gathered that most of the issues people had with it was caused by third party incompatible software and hardware.

finnjohnsen2 7y ago
No. It was Windows Longhorn. Microsoft abandoned it.
kryptiskt 7y ago
I also had little trouble with Vista and liked it well enough. But I had plenty of RAM, I believe it performed badly with 1 GB or less. And of course people got hung up on UAC.
- swiley 7y ago
  That’s kind of crazy. Firefox and libreoffice don’t do well in 1 Gig of ram but at least they’re doing something. You can run a decent DE and few decent apps in 1gig just fine with most Linux distros.
  - barrkel 7y ago
    And Microsoft Word ran perfectly well on 16MB of RAM in Windows 95, back in the day; and even better on NT with 32 or 64MB, productive and more than comfy. I guess my point is that running decent software on what today would be considered very little hardware is a solved problem, but it's not what the economy is optimized for.
    - swiley 7y ago
      The difference here is that LibreOffice is still maintained (in fact, the math typesetting in Microsoft office is practically unmaintained at this point and is just miserable to use.) Old windows (and old Linux) have serious problems that modern OSes don’t have. You can run modern good and compatible software in very little ram and the only reason not to is because someone else is forcing you or you’re just not aware.

amelius 7y ago

From the article: > In the replicated study the predictive value of organizational structure is not as high. Out of 4 measured models, it gets the 2nd highest precision and the 3rd highest recall.

nelsonic 7y ago

Does this mean that a solo developer working on a SaaS product can avoid bugs?

augustl 7y ago
That's actually very interesting IMO! Now that you said that, it seems obvious to me that there's a sweet spot somewhere, and that it's higher than 1 and (probably much) lower than 100.
donkeyd 7y ago
Well, in theory anyone can avoid bugs. It's just really costly and requires a very structured approach to doing anything. It's very unlikely, however, that you figure out every single combination of variables while writing tests. So, so in practice, I don't think it's possible to avoid bugs, unless you have a really tiny code base, maybe.
_ZeD_ 7y ago
surely this solo developer will avoid bugs regarding "communication misunderstanding" between the team elements.
- AnimalMuppet 7y ago
  I'm not totally sure about that. "Me, yesterday" has to communicate with "me, today", and communication misunderstandings can absolutely happen. Now, sure, such things happen less when it's me talking to me than when it's me talking to you. They still happen, though.
dredmorbius 7y ago
Days of yore when Bill Joy would rewrite / update Unix and userland over the weekend. https://invidio.us/watch?v=08PmIv1l5LY https://invidio.us/watch?v=08PmIv1l5LY

sorokod 7y ago

Conway's law strikes again.

chiefalchemist 7y ago

Code/technology is nothing more than a tool. A toolbox is only as good as the person/peoples who pick it up. That is a great tool will not save a disorganized organization. The great tool will not make a crap product better. Blaming the means for the ends is a classic n00b mistake. A mistake that's being made over and over and over again.

MontyCarloHall 7y ago

Looking at the metrics used in the publication[0], it seems most of them focus on the absolute number of engineers working on a given component. This makes sense — more engineers touching a component introduces more opportunities for bugs. (Edit: as other commenters have pointed out, total lines of code, highly correlated to number of engineers, is likely the best first-order predictor of bugginess.) I bet we can improve predictive power by considering the degree of overengineering, i.e., the number of engineers working on a task (edit: or lines of code) relative to the complexity of the task they’re working on. 100 people working on a task that could be accomplished by a single person will result in a much buggier product than 100 people working on a task that actually requires 100 people. The complexity of code expands to fill available engineering capacity, regardless of how simple the underlying task is; put 100 people to work on FizzBuzz and you’ll get a FizzBuzz with the complexity of a 100 person project[1]. Unnecessary complexity results in buggier code than necessary complexity because unnecessary components have inherently unclear roles. Edit: substitute "100 people" with "10 million lines of code" and "1 person" with "1000 lines of code" and my statement should still hold true. [0] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

augustl 7y ago
That's super interesting! What would be a good way to measure the comlexity of a task in some objective way? Also, the study doesn't really take "tasks" into account at all, it seems. Just modules and data relating to the modules.
- MontyCarloHall 7y ago
  >What would be a good way to measure the comlexity of a task in some objective way? From an existing codebase this would be very difficult to objectively assess. I think you’d have to study it empirically — come up with a set of tasks (“A”) that each takes a single programmer “P” on average a week to complete. Then come up with a set of tasks (“B”) that each takes a team “T” of 10 programmers on average a week to complete (ensure that 10 programmers is a lower bound, i.e. decreasing the number of coders causes the project to take longer). Across multiple solo programmers and teams, compare the quality of the code produced by programmers P on tasks A, teams T on tasks B, and teams T on tasks A. I’d bet P/A > T/B > T/A.

hos234 7y ago

Herbert Simon is who you read first when you thinking about orgs - https://en.m.wikipedia.org/wiki/Satisficing https://en.m.wikipedia.org/wiki/Satisficing That will take to you to healthy and productive places.

ChrisSD 7y ago

Previous discussion (which got flagged): https://news.ycombinator.com/item?id=21795462 https://news.ycombinator.com/item?id=21795462

tyingq 7y ago
I can't quickly tell why it was flagged. Was the study highly flawed? Or promoted in a dishonest way? Or was it really the comments as a whole that got it flagged?
- augustl 7y ago
  Probably because the title was originally extremely linkbait-y.

Merrill 7y ago

>Organizational Complexity. Measures number of developers workong on the module, number of ex-developers that used to work on the module but no longer does, how big a fraction of the organization as a whole that works or has worked on the module, the distance in the organization between the developer and the decision maker, etc. After one of the early big software project failures (maybe Multics?) there was a quote about software projects going around (maybe John R Pierce?) that "If it can't be done by two people in six months, it can't be done." One of the functions of good software design is to break the system down into pieces that a couple of people can complete in a reasonable length of time.

mirekrusin 7y ago

...which is likely proxy for complexity of the task - the more difficult the task, the more likely it'll have bugs - not an exciting revelation. Their "code complexity" means nothing. If you compare simple "todo web app" it'll have orders of magnitude more "code complexity" than, for example, sha256 hash implementation.

TheCoelacanth 7y ago
And rightly so. It is much easier to write a bug-free sha256 implementation than try to write a bug-free To-Do app.

kozak 7y ago

I have a Microsoft keyboard that has a dedicated Calculator button. In older versions of Windows, I used to press that button and start entering numbers right away. But in newer updates of Windows 10, I now have to press the Calculator button, WAIT FOR THE CALCULATOR TO LOAD, and then start typing my digits. I think this is ridiculous.

redleader9345 7y ago
Agreed. The market for super snappy user experience seems to be underserved. Maybe not enough demand? Or maybe a symptom of the "everything is free and paid for with advertising" model we have today.
chapium 7y ago
I don't share this experience. I think you have an underlying issue.
- kozak 7y ago
  This started happening when default calculator changed from a classic native app to the new "modern" app.
contextfree 7y ago
The calculator team has a GitHub discussion issue open tracking launch performance investigations if you're interested: https://github.com/microsoft/calculator/issues/209 https://github.com/microsoft/calculator/issues/209
contingencies 7y ago
If you were using Linux, solving your problem would be trivial. Practically, I can only recommend using a non-local calculator such as a search engine, since despite network latency that codepath is more heavily optimized and people now spend so much time in browsers. CTRL+L (address bar) then type "100+50/25=" and press enter. Bingo.

kabes 7y ago

The article ends with a mention of the book 'Accellerate'. Accellerate is your typical management book, based on some surveys with bad statistics and worse conclusions. Weird he mentions this book after talking about what a proper, replicated study Microsoft Research did.

zubairq 7y ago

I guess this is why startups exist because it it almost impossible for larger firms to execute good ideas even if they think of the idea themselves

moretai 7y ago
What is the underlying reason goliaths don't execute ideas well? Too many chefs in the kitchen?
- jgust 7y ago
  Political land grabs for the "new hotness".
- gfs78 7y ago
  Lots of freeloaders and incompetent power trippers in the middle layers and above. Small orgs. and startups cannot afford this kind of workers. In my current project (big co.) we have a technical PM, a non-technical PM, a non programmer dev lead, an scrum master and a lead business analyst, all involved in managing the work of a team of 2 and a half (a sr ba/qa guy, a part-time ssr dev and me). Waste work is probably in the 90%.
  - spookthesunset 7y ago
    > Lots of freeloaders and incompetent power trippers in the middle layers and above. Not just middle layers and up. Freeloaders and gatekeepers everywhere.
- hnick 7y ago
  In my experience it's risk aversion. They're more worried about losing out from doing the wrong thing or breaking what they have, than a slow death from decaying market relevance. It's much easier to stay the course than to stick your neck out asking to change things.
asdfman123 7y ago
I don't think that's true, but often times when you work in a large org building actually ANYTHING is like pulling teeth. Every decision you make is second guessed by 8 other people, and anything you do impacts 5 other teams. It's infuriating unless you're the type of person who loves working through people problems, and a lot of developers, including myself, aren't that kind of person. Also, maybe it has to do with the fact that failure is an expected part of startups, but in the business world there's perverse incentives to build something mediocre, expensive and ultimately useless just to give the appearance of success. With a startup, you're free to do whatever the hell you want. If it works, it works, and if it doesn't it doesn't. I guess it would be possible to give in-house teams free reign to try out new ideas without all the organizational friction, but the startup model works, so why not just throw some money at some kids and see what happens?

johnwatson11218 7y ago

The use of the term 'p-value' seems off, it looks like he is referring to a different concept but using an overloaded term.

habosa 7y ago

This rings true for anyone who has ever worked at a big tech company (I work at Google). At Google when your project begins to scale up you can ask for more money, more people, or both. Most teams ask for both. What you can't ask for is different people. You can't solve your distributed systems problems by adding 5 more mid-level software engineers to your team who have not worked in the domain. Yet due to how hiring works, this is what's offered to you unless you want to do the recruiting yourself. Google views all software engineers as interchangeable at their level. I have seen people being sent to work on an Android app with hundreds of millions of users despite never having done mobile development before. That normally goes about as well as you'd expect. So you end up with teams of 20 people slowly doing work that could be done quickly by 5 experts. In some cases all you lose is speed. In other cases this is fatal. Some things simply cannot be done without the right team.

natalyarostova 7y ago
I see the same thing, and the only way I can reconcile this is that the benefit to sr leadership in terms of treating SDEs as fungible is so massive that it is still worth the massive productivity loss from assuming exchangability.
- amznthrowaway5 7y ago
  What are the benefits to treating SDEs as fungible? At Amazon, Sr. Leadership and HR love to pretend all SDEs at a given level are interchangeable, level actually indicates competence, and leetcoding external hires with zero domain knowledge have far more worth than internal promos. All of the above assumptions seem completely insane to me and have resulted in the destruction of many projects.
  - natalyarostova 7y ago
    Yeah me too. Also at amazon. And yet amazon is obscenely successful, as are other big tech companies which take similar strategies. It seems that matching expertise to projects is so fucking hard that just giving up at the start and accepting it’s impossible is the optimal strategy. Honestly I don’t know. I agree it’s weird. But these companies keep succeeding doing it this way, so I’m not sure what to make of it.

neilobremski 7y ago

I think all current and ex Microsoftees can agree (and probably other workers in Big Tech Corp) that this is not only obvious but ongoing and dastardly resilient to getting solved! At some level this must be a sociological thing because humans seem to be hardwired into repeating this mistake. This happens at smaller companies in smaller ways but the effect is the same. It's worse than the "Mythical Man Month" in that production is not simply slowed down but it is slowly made rotten until it gets burned, buried, or passed off to out-sourced maintenance.