Matt, I thought your comment was pretty insightful. I remember when I was working on a rails project and finally “got” it that doing the tests in an automated way would actually be faster in addition to being less error-prone. It would certainly help to be in the flow better. Perhaps there are other high value activities, but it seems like everything adds up. My understanding of the piles and pipeline part is that you have large batch sizes that move through the system. I could have misinterpreted this.

Granger, I have had similar problems in the past with not having enough important work queued up. Perhaps there is a feedback problem nonetheless? Would getting things to the client and approved assist them with knowing what has been done and what the next steps are? I agree that the queue would be helpful. I’ve found it hard to enforce having the queue be filled if the client does not see filling it as urgent. I guess this is where making a business case for lost value would be helpful.

I like thought experiments like this because they kind of put me in brainstorming mode versus analytical mode. Instead of thinking “I can’t”, I think, “What if?” Anyway, the delay that I would most like to have removed on one of my projects is the time from when I believe that I am finished to when I get feedback about the solution. When the code is still fresh in my mind is the best time to work on fixing it or changing something. When things go stale I am more likely to have errors. Plus, it feels good to have that more immediate feedback/gratification of delivery. The “atta boy”, if you will. There are other things that would be great to change, but this is the most important for me at the moment. Hopefully this realization will assist me in reducing the delay.

Thanks for your comments!

You can do this currently if your queue of work is kept full and sorted. If you don’t have a queue, there’s communication lag along with decision lag in the way.

Then again, I sometimes find that decision lag can be beneficial in helping a customer figure out what they need and/or want.

Achieiving this would drastically speed up the occassional but inevitable period where I do cosmetic and behavioral tweaks toward the end of a feature. Not that I’d ever allow myself to fall into the rapid cycle tweak-n-build frenzy that hallmarks development-by-accident. I am, afterall, a True Professional. (Whatever!) But plenty of times, having “Ctrl+S, F5″ turn-around-time would make the difference between “stable by lunch” vs. “waiting until I can set aside a few hours this afternoon”.

In the way of achieving this: The reality of ASP.NET and C#, IMO. You build, you usually lose your session. There’s shut down and restart time. It’s the age-old compiled vs. interpreted thing. For non-GUI parts, I think following a TDD approach would help as we can possibly avoid the web overhead. Becoming more savvy in tweaking ASP.NET builds and dev environments might help.

And none of what I just wrote is terribly interesting. It’s a micro-optimization compared to the level you’re talking about (I think), given your (probably) lean process. You’d have to be pretty darn streamlined already for it to be a heavy hitter. And despite how I’ve talked it up, it’s not even in the top 5 most valuable improvements on my project. My project is so decidedly non-lean that fixing any one delay isn’t going to result in a productivity breakthrough. Delay reductions are nice but we simply aren’t geared to exploit them. We’re more piles than pipeline, if you grok.