3 ms·

How humans kill companies

30 points by jpadilla_ 14y ago

fatalerrorx3 14y ago
Way too involved in your team's day-to-day- I'd say that's a pretty big issue. When you hire a designer to design, and you're telling them where to place things and what they should look like when you yourself have no background in design, that's a sure-fire way to bring a company down
fleitz 14y ago
The problem is that office politics are usually the only way to resolve issues within a company. Invariably there's someone tasked with deciding which language something will be developed in, whether you can develop something in a given language, etc. Usually these things are decided based upon whether the stupidest programmer in the room can program in this language, and whether in general bottom of the barrel programmers can use that language. Whenever you see Java, PHP, or C# you'll usually find the reason has something to do with the ability to hire 200 programmers to do the work of 2 or 3. This is the office politics that kill companies, the usual Jimmy doesn't like Frankie stuff is minor and easily dealt with. Also, it generally only actually kills the company once a competitor is operating inside their OODA loop. In general with out a competitor that doesn't have office politics there's no serious threat to the organization.
- jacquesm 14y ago
  > Whenever you see Java, PHP, or C# you'll usually find the reason has something to do with the ability to hire 200 programmers to do the work of 2 or 3. You can do a lot better than that. Java, PHP and C# are sometimes simply the right tool for the job, and no programming language gives you a 100:1 advantage. That's simply ridiculous.
  - fleitz 14y ago
    The right tool in the right hands will certainly give you that kind of advantage. It's not in language alone, but combined with the craftsman, the level of trust in the team, and the process, certainly. Once you have 200 programmers you have to have managers, architects, etc, and you have communication overhead. I'd say off the top your communication overhead is 50%, so lets say you now have 100 programmers available to program, and 100 to communicate. Now to use these 100 programmers effectively you need them to work in parallel, in any project you usually have layers so some programmers simply won't be able to do anything because they are waiting for someone else, lets say outside of meetings these programmers are actually programming 75% of the time, now you have 75 programmers. Lets say java is twice as inefficient in terms of LOC as ruby, now you have 35 programmers, lets say a ruby rockstar is 10X what the average java programmer is, now you have 3.5 programmers. When you walk into your typical large corporate dev shop you can take on many times the workforce with a small team of dedicated craftsmen who trust each other. Whether it's 50:1, 100:1, or 200:1 I'm not sure, but I am sure that it's in that ballpark.
    - jacquesm 14y ago
      I challenge you to write an application like Wowza in ruby. Java is insanely performant for some workloads, as a long time C hacker I think that is interesting because this used to be an area where C was unchallenged and now java has achieved parity there, and in some situations can exceed C. Ruby and other glorified scripting languages need not apply. LOC is not a useful measure for productivity anyway, I thought we had put that to rest a while ago. What matters is whether or not the stack you are using gives you what you need, if what you need is fewer lines of code because you've made that a metric then you are missing the wood for the trees. Long term what matters is maintainability, control of the development process (which you should be able to achieve in any environment but which appears to be problematic in some), your ability to find employees and so on. Lines-of-code never was a business deliverable and it should not be, it does translate into some measure of cost in the longer term but that cost can be offset by lots of factors.
helloamar 14y ago
Black sheep do exists everywhere even if you find them and fire them, they go out and create rumors about the company. I've faced this twice.

30 points by jpadilla_ 14y ago

Way too involved in your team's day-to-day- I'd say that's a pretty big issue. When you hire a designer to design, and you're telling them where to place things and what they should look like when you yourself have no background in design, that's a sure-fire way to bring a company down

fleitz 14y ago

The problem is that office politics are usually the only way to resolve issues within a company. Invariably there's someone tasked with deciding which language something will be developed in, whether you can develop something in a given language, etc. Usually these things are decided based upon whether the stupidest programmer in the room can program in this language, and whether in general bottom of the barrel programmers can use that language. Whenever you see Java, PHP, or C# you'll usually find the reason has something to do with the ability to hire 200 programmers to do the work of 2 or 3. This is the office politics that kill companies, the usual Jimmy doesn't like Frankie stuff is minor and easily dealt with. Also, it generally only actually kills the company once a competitor is operating inside their OODA loop. In general with out a competitor that doesn't have office politics there's no serious threat to the organization.

jacquesm 14y ago
> Whenever you see Java, PHP, or C# you'll usually find the reason has something to do with the ability to hire 200 programmers to do the work of 2 or 3. You can do a lot better than that. Java, PHP and C# are sometimes simply the right tool for the job, and no programming language gives you a 100:1 advantage. That's simply ridiculous.
- fleitz 14y ago
  The right tool in the right hands will certainly give you that kind of advantage. It's not in language alone, but combined with the craftsman, the level of trust in the team, and the process, certainly. Once you have 200 programmers you have to have managers, architects, etc, and you have communication overhead. I'd say off the top your communication overhead is 50%, so lets say you now have 100 programmers available to program, and 100 to communicate. Now to use these 100 programmers effectively you need them to work in parallel, in any project you usually have layers so some programmers simply won't be able to do anything because they are waiting for someone else, lets say outside of meetings these programmers are actually programming 75% of the time, now you have 75 programmers. Lets say java is twice as inefficient in terms of LOC as ruby, now you have 35 programmers, lets say a ruby rockstar is 10X what the average java programmer is, now you have 3.5 programmers. When you walk into your typical large corporate dev shop you can take on many times the workforce with a small team of dedicated craftsmen who trust each other. Whether it's 50:1, 100:1, or 200:1 I'm not sure, but I am sure that it's in that ballpark.
  - jacquesm 14y ago
    I challenge you to write an application like Wowza in ruby. Java is insanely performant for some workloads, as a long time C hacker I think that is interesting because this used to be an area where C was unchallenged and now java has achieved parity there, and in some situations can exceed C. Ruby and other glorified scripting languages need not apply. LOC is not a useful measure for productivity anyway, I thought we had put that to rest a while ago. What matters is whether or not the stack you are using gives you what you need, if what you need is fewer lines of code because you've made that a metric then you are missing the wood for the trees. Long term what matters is maintainability, control of the development process (which you should be able to achieve in any environment but which appears to be problematic in some), your ability to find employees and so on. Lines-of-code never was a business deliverable and it should not be, it does translate into some measure of cost in the longer term but that cost can be offset by lots of factors.

helloamar 14y ago

Black sheep do exists everywhere even if you find them and fire them, they go out and create rumors about the company. I've faced this twice.