[IWE] Gory details -- UPDATE

[Ben Tilly]

On 2/7/06, Drew Kime <drewk98@yahoo.com> wrote:
> --- Ben Tilly <btilly@gmail.com> wrote:
> > Hold out for cash, and keep your resume updated.
>
> Momma didn't raise no dummy.

:-)

> > Sight unseen I'm going to guess that anyone competent looking at
> > the state of their code and process would say that it is faster to
> > deliver the original project, as asked for, by developing it from
> > scratch with a good team.
>
> Then either I'm competent, or you're wrong.

As I said, I'm guessing here.

However this guess is based on both theory and observed experiences of
both good and bad teams in action.

Here is an example of the theory.  Standard estimates are that fixing
bugs downstream costs 10 to 100 times more than fixing them in design
and requirements.  And most projects incur most of the cost of their
project in the maintainance phase.  Therefore the extra cost of
maintaining a poorly written piece of software can very easily dwarf
the cost of developing it properly.  Not to mention the hidden
opportunity costs when people suffer with software that doesn't do
what they need because it is too hard for anyone to change it.

Your description of their attitude towards bugs *strongly* suggests
that potential bugs have not been fixed upstream, and therefore you
will incur the worst-case costs.  Which will eat you up on
maintainance and inflexibility.

Here is an example experience.  Where I currently work a very bad team
of 15 people had developed the website in VB running through ASP on
Windows.  It was very buggy, changes were hard to make, and it was
falling over at ten thousand pages per day.  A competent group of 3
developers in less than 3 months redeveloped the site in Perl running
in mod_perl on Linux.  Upon release the site had far fewer bugs and
scaled much better.  The site that we now have is vastly more complex
and does millions of pages per day without trouble.

Note that the technology was not the key difference.  The developers
were.  But it is far from coincidence that the competent developers
chose a very different platform than the original PHBs who set up the
incompetent team...

Of course the problem is that this approach requires a competent team.
 Identifying and bringing a competent team on board is extremely
difficult for problem organizations to do.

Cheers,
Ben