Archeological Dig

Gustavo Barrancos 24 minutes later:

• • Shocked… Never imagined that the original idea of Waterfall consisted on concurrent phases. Waterfall as i always knew was just a TON of up-front design (months) without any implementation. What worries me most is the fact that distortions like this one on the “Classic Waterfall” are kinda haunting agile methods like Scrum these days . Will story repeat itself?

  • Thanks for sharing, BTW!

GBGames 26 minutes later:

• • The final slides talk about the importance of measurements, and I know a lot of people, especially management, are interested in statistics. While the slides talk about measuring individual slices and having those measurements work between projects, I’m pretty sure I’ve seen the opposite said when it comes to TDD.

  • That is, measurements for one project only apply to that project. And that’s assuming someone found a good metric. Code coverage and number of unit tests on one project can’t easily be used as a base to measure other projects with, for example. Are the four metrics listed on the last slide still valid when it comes to modern, Agile projects?

Curtis Cooley 37 minutes later:

• • That is pretty amazing. I could see any agilist using those slides to introduce people to XP.

  • I remember back in ‘97 the Spiral concept was coming around, where you do Waterfall, but spiral back to Analysis and Design. As the project runs, the time in each phase changes. Less in Analysis and Design and more in Implementation and Test. I remember that resonating with me.

  • I was at Getronics building bank teller software and the QA manager was trying to get the company to adopt the “Microsoft Solution Framework” which basically was a spiral waterfall. Almost iterative :)

  • I never understood why they called it waterfall. Falling off waterfalls is almost always bad.

Chris Vest 42 minutes later:

• • That was interesting. I also sensed some parallels to responsive design, as I understand it.

  • It makes me wonder that maybe the “good way” (for lack of a better term) to built software is a force of nature – the nature of software; the languages, the problems and the tools. So the “good way” is not something that we invent or engineer or refine, but rather something that is (have been gradually)discovered.

  • Such an immutable nature, and the “good way” it implies, do sound like a solid foundation to build a craft upon. :)

  • Will we look back on these blog posts in fifteen years and be struck by how they sketch up the basics of the practices and processes used by then?

Dave Rooney about 1 hour later:

• • From the slide “Analysis and design are not binary Deliverables”: There is no way to tell when they are done, so they are always done on time.

  • I love it!! I’ve asked the question, “How do you know that ‘Requirements’ are 100% done” before, and no one has ever given me an answer. :)

Al about 1 hour later:

• • Outstanding! Thanks for sharing.

Patrick Logan about 2 hours later:

• • I still think your C++ book (yeah that one with the really long title about “booch method”) is probably the best on OOP ever written for any language. I still recommend it to java programmers, etc. Roughly the same era I guess. How come people still write such bad software?

Kenny about 2 hours later:

• • Uncle Bob,

  • Are you sure you didn’t give this presentation at a recent keynote? It amazes me that no matter how long you beat the drum there are still people out of step.

Bill Sorensen about 2 hours later:

• • There are echoes of Lean here as well. Very nice!

Jason Smith about 2 hours later:

• • @Patrick Logan—good to see I’m not the only fan of that book! Actually, one of the arguments I used to justify purchasing that book for my teams was how pragmatic RCM was.

Giorgio Sironi about 4 hours later:

• • I guess good design is timeless..

Szymon Pobiega about 13 hours later:

• • It is amazing that now, 15 years later, in my environment nothing really changed. How can it be that when you tell your boss that we shout try billing for time and material, he tells you that nobody would buy our software? And the boss is right, only the market seems to be wrong—immature. I wish it was as easy here, as in the US…

Amy Thorne about 22 hours later:

• • It’s disturbing how relevant those slides still are today.

  • All I can do is repeat Kenny’s comment, “It amazes me that no matter how long you beat the drum there are still people out of step.”

  • How do we make people listen? How do we make them understand?

  • I feel like when we the developers tell people these things, they don’t listen, and then when projects run behind and code gets brittle, they come back and just blame us, since as the slides point out, “Implementation is a binary deliverable so it is always where the debt accrued by analysis and design is paid.”

  • But at this point, when we (again) explain that part of how to fix the implementation problem is to change the development lifecycle, we’re told things like “It’s not your job to tell us how to run the lifecycle, it’s your job to write code.” Or “We need to do waterfall, because we need to promise our clients that we will give them Feature X on Date Y.”

  • And again, we’d like to help them understand that there may be other models, but that’s not our job, so no one listens or even gives us time to explain. They just tell us to go back to writing code—after all we need to get our butts in gear and write that code, we’re behind schedule!

Joshua Lewis 23 days later:

• • I am amazed at how visionary you were. A lot of those concepts correspond so well to modern ‘agilist’ principles and practices.

  • The statements on the slide “Analysis and design are not binary Deliverable” really resonated with me.

  • Very insightful that ‘analysis and design’ cannot be measured as done or not. I think that statement alone is motivation for iterative/incremental methods.