Good advice on the learning schedule. That could apply
to many parts of the SDLC. It's amazing how many times
you seem a development shop building an app, where they
do a little digging on the web, and determine they need
this or that web framework (Spring, for example), this
or that persistence framework (Hibernate, for example),
etc etc, they've tried to overwhelm the problem with
technology and find themselves mired in complexity, when
they could've knocked this out in a minimal sort of way,
using .NET or PHP and be done with it.
I remember long back working on a large Ariba system at
one of the big retailers. They were using Net.Commerce
(now WebSphere Commerce Suite), which had originally
been written for L.L. Bean by a very clever team. Back
in the day before XML configuration and IoCs like Pico
Container and Spring, it was all table-driven. So when
this company, which had built it's commerce engine from
scratch, realized it would be nice if they could have it
more customizable (oops!), purchased Net.Commerce.
It had it's own macro language, Net.Data, sort of
JSP-like perhaps, and then the controller code was
written in C++. Anyway, this being a retailer, we were
working on a tight deadline, trying to get all our code
working, your typical integration test scenario with the
Ariba code, webMethods scripts, Net.Commerce C++, even
some Java, then the back end system - you name it. But
it didn't work. Time for some laborious troubleshooting.
Finally we traced it to the C++ "command" code. I
confronted the developer - it was a basic, trivial
coding error, that would've been caught if he had unit
tested. His code simply did not work! This was not even
some strange data or unexpected condition, it friggin'
simply was broken! Unbelievable.
"But it compiled!! It's too hard to setup a unit test in
C++!"