

Ego-Driven Development - dmiladinov
http://deliberate-software.com/ego-driven-development

======
jff
Sometimes it's not so much "NIH syndrome" as "Everything else really, truly is
crap". Scottschulthess mentiones that all CMSes are terrible. Some of my
colleagues, for example, needed to spin up hundreds of virtual machines very
very quickly, and as it turns out, OpenStack is absolute crap. So they took 2
weeks and wrote something a fraction of the size of OpenStack which can have
hundreds of virtual machines running in the time it takes OpenStack to boot up
1/10th as many... and crash.

~~~
zrail
Would they consider open sourcing what they made? Sounds very interesting.

~~~
jff
They're working on it, and I'll make sure to post it on HN when it goes open
source.

------
scottschulthess
""Not Invented Here" syndrome: Expressed most commonly in a desire for
everything needed to be developed in house. E.g.: “Need a CMS? Let’s make our
own from scratch!” Perhaps, you work at a place where all your teammates do is
constantly bring you bad ideas. Are they really all terrible? Or are only your
ideas good enough for the organization? Not Invented Here can also apply to
your own head, not just the organization."

The answer is yes, they (CMSes) are all terrible. :)

"No dedicated QA for externally-facing software: Someone who is experienced at
breaking software should have a crack at it before it goes to users.
Developers (including me) are too enamored with their own work to really take
the time to break it, so someone with a sense of pride in finding problems
needs to be given the task."

Having dedicated QA is not always good. In fact it is often counter-
productive.

"Low Joel Test score: The Joel Test remains a great indicator of institutional
ego. A team that scores low on the Joel Test does so because someone along the
way decided that, "nah, we don't need that here, we are special", and almost
certainly they are not. I have yet to hear of a team with a legitimate reason
for a low Joel Test score."

The joel test is actually quite out of date. Specifically the stuff about
fixing bugs before writing features, hallway usability testing, testers,
having a 'spec', and having a bug database are all not necessary or good to
have in all cases.

~~~
hack_edu
> Having dedicated QA is not always good. In fact it is often counter-
> productive.

Maybe 'dedicated QA' is a bad but a developer must at least be point man for
test, even if the responsibilities aren't 100% of their workload. One could
argue that having a horde of peons to click randomly is counter-productive,
but teams >6 or so need a specific dev responsible for automating test. Its
too specific a domain, and intermittently demanding, and to force all devs to
split the duties.

~~~
scottschulthess
Sure. Though I probably would spread the automated testing workload among the
whole team as opposed to appointing one person.

------
fabrizioc1
There is the other side of "NIH syndrome".

In order to "save development time" and implement "best practices" a company
decides to use an "out of the shelf" package from a big name vendor (IBM,
Oracle, Microsoft, etc) and customize it to their needs. Some initial
customization is done and some shortcuts are taken to make the project go
live.

Fast forward a couple of years. The custom code added by the company
complicates upgrade paths and vendor support. The business demands more and
more functionality which the package does not support "out of the box".

The customization initially implemented turns out to have been technical debt
in disguise. They bypassed the recommended usage of the package or platform
which resulted in performance problems. Eventually they end up having to re-
work everything "the right way" in order to get vendor support or fix the
performance problems.

This is specially prevalent in corporate IT departments in large corporations.

Moral of the story is that "off the shelf" platforms are not a silver bullet.
If you don't understand the platform and the business requirements you will
have problems later on.

I don't know how many times I've fixed performance problems of "off the shelf"
packages by simply writing code which replaces the OOB code with a couple of
SQL queries/stored procedures and only does what the business needs, bypassing
features which the customer does not need in the present.

~~~
samspot
There will always be problems and headaches with off the shelf software, but
the thing is that even with all of this you may still save over building it
yourself. I worked for years on a Siebel implementation, and even with these
issues it was worlds better than the previous incarnation which we had built
in house.

------
lmm
I used to apply the Joel test religiously, but I've gradually come to the
opinion that dedicated QA is a net negative. It creates a natural opposition
between two halves of what should be the same team, and removes the focus that
comes from knowing that what you create will be what's deployed. It also adds
friction that goes against the agile "deploy early, deploy often" approach.

~~~
Osiris
Anecdotally, I can say that I've seen the issue with QA causing code
deployments to take far longer than they should. For example, right now we
have code (one small feature) that QA wants almost two full weeks to test. I
was just telling one of our QAs that I hope we start getting much better
automated test coverage so that manual QA time can be brought down to a much
more reasonable day or two before releasing code to the public.

~~~
wonderzombie
Some of it comes down to incentives/culture. If QA gets yelled at when bugs go
out, they're going to take a conservative approach.

It's funny, though, to hear you "hope" you start getting better automated test
coverage. :) It happens pretty often that QA is the sole owner of automated
tests, which has its own set of potentially bad incentives.

------
bajsejohannes
> developers and managers repeatedly act as if established best practices do
> not apply to them

... and rightly so. A junior programmer might be better off always following
"established best practices", but I expect any developer worth their salt to
be able to know _when to break the rules_.

~~~
mtshark
Is it really a best practice if there's a better way of doing it?

~~~
jmcqk6
"Best Practices" are not always well defined or applicable. In some cases
there are conflicts among different practices. Even worse, there are cases
where one person believes something is a best practice and another believes it
to be a bad practice.

The reality is that there isn't really such thing is a 'best practice.' There
are only practices that have been found to be 'less wrong' than other ways,
and perhaps even 'useful.'

Whatever your development practices are, the important thing is that you have
and maintain the flexibility to adapt to what the particular situation needs.

------
zio99
Add two more to the list:

1\. No documentation

2\. Over-engineering

I believe EDD affects everyone from the large corps right down to the one and
two-person teams. Take a look at highest upvoted hacker ideas here:
<http://www.todaystopthing.com/hackerideas/top>

They tend to satisfy the "technically challenging" and EDD trap. Now check out
the flop ideas: <http://www.todaystopthing.com/hackerideas/flop>

Some of these products exist and are profitable. "Simplifying" a
problem/solution doesn't make it any less of a project worth pursuing. Great
read +1.

------
OldSchool
Hmm, just playing devil's advocate here but I'll bet that a huge list of
successful people topped by the obvious like Gates, Zuckerberg, and even the
humble Wozniak have used all of these elements some or most of the time in
their development lives :)

Generational differences abound and manifest in management trends as people
reach an age of influence. Born in the 50/60's - you're more likely to be a
lone-wolf type. Born in the 80's/90's and you probably consider teamwork and
connectedness to be instinctual. Not claiming either is correct but certainly
projects beyond a certain scale can only be completed by a structured team.
Too, those who prefer to work alone are not automatically egomaniacs.

~~~
JackMorgan
You are certainly correct that there is probably a huge list of successful
people who have used these elements, and that is fine, but that doesn't mean I
want to work for them! I have heard people say working at Apple is horrific,
as that ego is permeated into everything they do. Sure they (used to) turn out
great work, but at the cost of a terrible work environment. Check out the book
Good to Great
[http://en.wikipedia.org/wiki/Good_to_Great#Seven_characteris...](http://en.wikipedia.org/wiki/Good_to_Great#Seven_characteristics_of_companies_that_went_.22from_good_to_great.22),
notice that first thing? Humble leaders. Notice what is happening to Apple
lately without that massive ego whipping them onward?

As to the generational differences, I had not noticed only the older devs
wanting to "cowboy" while the younger devs "cooperate". Usually, it has been a
variety of both doing both. I will have to keep my eye on that though.

------
mbustamante
every software company in the US is using pair programming ? is that wrong not
having pair programming ?

~~~
dmiladinov
Pair programming is a great way to get new developers up to speed with the
code-base, but the team that is going to be using it long-term needs to apply
it with discipline.

~~~
samspot
I have always thought the concept was great, but I have struggled with how to
implement it.

~~~
JackMorgan
My preferred method for training right now is "promiscuous pairing"
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&#...</a><p>As for hardware
setup, the best I have used is: machines with cloned monitors, two mice, and
two keyboards, both side by side so the developers can talk in low tones and
not bother anyone else. I do this now at work, and it is a lot of fun, and it
really averages to be that we get done more than twice what we would work
normally alone.

~~~
emeraldd
@JackMorgan and @dmiladinov, you two have eerily similar timing and views on
this one :) Any chance you're co-workers and happen to know Steve?

~~~
JackMorgan
Well, I am Steve, the author, and yep, we used to work together a few years
back.

------
chicceo
This is a great article. I have never heard of this, but it's so true - thanks
for the insight.

------
julianduque
Hmm, I can tell I work for a company that do that. Thats sad :(

