The "Two Minutes To Midnight" Strategy In Software Development
It seems like the first 75% of time in the majority of projects is wasted for things without any additional value. At the beginning of a project there is not a lot of pressure, so a lot of time is spent for esoteric discussions, unrealistic evaluations and production of "write only" documents.
It seems like developers are not allowed to start with development until the "ivory tower guys" found the ultimate solution. Such a solution rarely exists in the practice, so after the majority time is wasted, developers have to hack the application in the fraction of the initially planned time.
Its a pity, because instead of discussions and documents, the time could be spent for the creation of spikes, PoCs or prototypes. It is a lot easier to evaluate working code, than nice looking presentations, or bubbles.
I'm sure the agile people have already a (japanese sounding) term for the "Two Minutes To Midnight Strategy":-).
Hi Adam
Well there's an expression for what you've described: Kaizen, continuous improvement by reducing waste:
http://blog.eweibel.net/?p=489
Patrick
Posted by Patrick Weibel on November 29, 2009 at 12:58 PM CET #
Hi Patrick,
kaizen is a useful theory from the "Toyota Production System". Not sure whether it will help - the first iterations are wasted - but at the end the team becomes productive :-).
Posted by Adam Bien on November 29, 2009 at 03:24 PM CET #
If the overall idea for a project is clear enough, and can be splitted into meaningful tasks from the beginning -otherwise it's not a project-, I believe the best thing to do is to start producing code, for each task, from day one, without any delay.
It's far more easier to rethink, adapt, modify, enhance, or throw away, true written and somewhow working pieces of code than "vaporware".
I guess there's always some sort of fear about refurbishing and glueing together existing code, which tends to a seat and wait attitude, in the hope the "magic solution" will drop down from skies.
I'm not defending at all a "brainstorm style" for programming, but without a type, retype, and type again attitude, I don't see how a project may see some light in time.
Posted by Carlos on November 30, 2009 at 02:06 PM CET #
It really depends on the type of project. And yes, I know that's little like saying "add sugar to taste" -- as if you'd add an amount of sugar you don't like if you hadn't been told.
If your project is relatively well-defined, then I concur that any work that isn't producing or testing something concrete is probably wasteful. But that "relatively well-defined" means some thought-work has already happened up front, even if it is the coincidental work of having struggled on a different project or in the business market and then having realised "what would really help is...", of if another team working closely with the customer has already done the work to find out what's needed.
If your project is more towards the R end of R&D, though, then there really is a lot to be said for spending some time making sure you're pointed in the right direction before you start running. It is a lot quicker to think through, thrash out, reject, and revise thought experiments, sketches, whiteboard mishmash, mock-ups, Wizard-of-Oz trials, and discussions with potential customers, than it is to throw away 10,000 lines of code that did the wrong thing and start again. Worse, even when you have only say 1,000 lines of code, you might be tempted not to throw them out -- and instead write another 9,000 lines of code that's still not going to be useful in the end -- because you don't want to "waste" your early efforts. And then another 90,000 to save wasting the 10,000...
Yes, PoC code, spikes, and prototypes most certainly do need to be done and tested -- I'm no advocate of the "waterfall" (unless you like getting cold and wet) -- but before then, thought prototypes need to be tested that don't even take *any* code to write.
Where "write-only documents" are produced, I tend to find they are generated by accountability and management processes rather than design processes. Very few "ivory tower guys" want to spend hours writing an irritatingly overspecified document for the sheer beauty of it. Far more do so because their HR-mandated performance review plans require a Key Performance Indicator, and that KPI can't just be them saying "we had a great idea, honest, guv". Most people I know really do "write to be read". But perhaps I've just been lucky about who I've been working with.
Posted by William Billingsley on December 01, 2009 at 05:14 AM CET #
And so it's not very suprising once you got at least all the functional requirements implemented and try to go live you will discover that operations has some more requirements to monitor, support, update and scale your application.
I suggest:
Get working code deployed as soon as possible on a real production system. If you can let some some end users perform their tasks with the old and the new process/software. Saves you a lot of trouble and minimizes many operation related risks.
This helps both sides: developers can start coding early on and the business guys get some risks minimized which are otherwise not really covered at all.
Posted by Java Administration on December 03, 2009 at 06:36 PM CET #