more folks should follow the WISKY principle… NOT!
(Why Isn’t Somebody Koding Yet?)
in 1995, my team and i were architecting a C++ solution for IBM’s next-generation manufacturing software. i had a crack team of 6 senior engineers/developers.
while i was gathering requirements and building object models, sketching UI ideas, and doing release planning; others on the team were building out (coding) the technical architecture we envisaged for this radical, thin client system. i also had my team setting up some real world simulation tests to thrash the architecture about, poke and prod it, and see if it was robust enough for our use.
the client was getting restless/antsy… they wanted to get moving on development of the whole app. they wondered “why aren’t more people coding? won’t we finish sooner if you have a couple dozen people working from the start?” but in reality, it seemed they wanted to bring on the dozen or so developers that were allocated and start billing them out and to report some “progress”.
i remember telling management “flat out” that if they insisted on bringing forth the horde of developers, the developers would just sit there and do nothing until my team and i were ready for them. i explained that this up-front work was essential to getting the team propelled in the right direction, with the right architecture, and consistent coding standards and coding templates. i also mentioned that this normally required about 10% of the project effort.
i got my way. no WISKY was allowed! (Allowing a bunch of developers to begin to develop prior to understanding the architecture, coding patterns, and the basic priorities is a big mistake.)
A few weeks later, we were ready to begin and brought in the other developers. By that time, we had our thin-client, layered architecture determined, and a pattern for folks to follow.
(footnote: the 3 months upfront was pretty close to that 10% mark, for the project ended up being ~3 years, ~250 domain classes, and ~1 Million LOC. This was my first large “agile” project.)