
How humans kill companies - jpadilla_
http://hitenism.com/how-humans-kill-companies/
======
fatalerrorx3
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
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
> 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
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
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
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.

