4 ms·

> 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

by 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.

by abiox 9y ago

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.