4 ms·

> Compare with Google isn't google's situation a monorepo composed of many distinct projects? there doesn't seem much utility in the comparison. > Email isn'

• jasode 9y ago
  >using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions. I don't think that equating it from the reverse direction works. Here's why: Using the article's count of ~4000 developers, let's consider all software companies that employ 4000+ developers as part of a "natural experiment"[1]. This includes companies and organizations like MS, Facebook, NASA, SAP, Oracle, etc. Each company "votes" in the marketplace of ideas to coordinate software development for a complex project. One company might use JIRA. Another uses MS Team Foundation. Another uses FogCreek. Maybe another employer might use SMTP emails similar to Linux kernel development. Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible. Since no single software company I know of uses SMTP emails as their ALM workflow, it either means that (1) companies are wasting money & losing iteration velocity by avoiding email -- or -- (2) the Linux kernel community has special circumstances that makes using a true unified ALM unrealistic. I believe that special circumstance is: 4000 programmers work for different employers instead of a single employer. [1] https://en.wikipedia.org/wiki/Natural_experiment https://en.wikipedia.org/wiki/Natural_experiment
  • abiox 9y ago
    > Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible. in the abstract these are generally viewed as or presumed to be positive, but the pressures and objectives of a business can be rather complex and other things will often compete for finite resources. having worked in a number of large organizations, the waste and inefficiencies one can find is absolutely staggering. outside the sales pitches, it's also not clear how an alm interacts with notions of 'cost-efficienty' and 'velocity'. introducing process and bureaucracy isn't always a win. perhaps the presumed predilection of large organizations for alms can be found in alms addressing (or seeming to address) other needs, pressures or requirements.
    • jasode 9y ago
      >having worked in a number of large organizations, the waste and inefficiencies one can find is absolutely staggering. Sure, I agree this is true in a general sense (Dilbert cartoons, Peter Principle, etc). However, for things like choosing technology to help with market superiority, companies (especially software engineering companies) will eventually gravitate to something better. We could argue that companies are "inefficient" for not embracing remote work-from-home instead of open offices, etc. (general inefficiencies). But, even badly run companies don't insist on using inferior floppy drives instead of USB drives or wireless network file transfers. Yes, a law firm might limp along with an 15-year old version of Microsoft Word 2000, but a software engineering company will not. (technology inefficiencies) > introducing process and bureaucracy isn't always a win. The Linux dev community also has process & bureaucracy. See my previous link for the strict and precise formatting rules to submit kernel patches in emails. That's process. Just because it's not in a web form with fields doesn't mean it's not "process". They're just using emails as the workflow for it. (Linus has famously chastised contributors for not following "the rules".) Process & bureaucracy is not bad thing -- its effort just has to match the scope of work being delivered. (E.g. using JIRA for a "hello world" toy program is overkill.) The Linux kernel community seems to have converged on the level of bureaucracy that works for them. It's interesting that even young YCombinator companies with much less than 4000 employees also don't stay with SMTP email-as-ALM as they get bigger. If email-as-ALM was a better software dev philosophy, there would be a huge arbitrage opportunity to outcompete everybody. Instead, the email-as-ALM fits Linux kernel devs' specific circumstances.
    • makapuf 9y ago
      having worked in large and small orgs, what I can say is, sure, a large org has many more inefficient workflows and latency than a smaller one. However it also has much more drive than the N independent smaller orgs it needs to accomplish the same scope. As a whole, a bunch of 10 person startups is generally more inefficient to accomplish something a big enterprise can do. (and of course, to accomplish what a startup can do, a big org won't be able to do for ages. Formula one vs huge train.) My point being, dont compare a big organization with a small team. Compare a small team within this org with an independant team. The indeêndent team wins, but not by far. With several competing small startup, the thing is, you cannot see the inefficiencies.
  • marcosdumay 9y ago
    Or, alternatively, ALMs provide some other kind of value (that is iteration velocity or efficiency) that Linux developers don't care about.
    • jasode 9y ago
      >Or, alternatively, ALMs provide [...] iteration velocity [...] that Linux developers don't care about. I agree and that's why the author quoting Greg Kroah-Hartman about commit velocity (throughput of "8 changes per hour") in his article is actually a distraction from answering the actual question as stated in the article's title. The real reason for kernel devs use of emails isn't the throughput.