On mailing lists, when I speak, in email, people ask, “When did ’some principle, approach, or whatever’ start?”
A long time ago.
Timeboxes have been around forever. I’m pretty sure that when the Pharoahs told their architects to build a pyramid, they said, “And do it by this-date! Or else!” I know that military projects used timeboxes. We used them in the mid-70’s and I heard that they were used when my managers were young engineers.
Inch-pebbles were first defined by some Air Force guy in the 40’s. (That’s the first published date that I know of.) The Software Program Manager’s Network (and I!) publicized the concept more in the 80’s and 90’s.
Non-waterfall lifecycles, such as iterative and incremental have been used for years. Any of those projects where you had to show a demo partway through the project was either an iterative or incremental lifecycle. The projects I worked on in the 70’s, 80’s, and 90’s had feature-based teams where we had to finish our features and integrate and test as we proceeded.
What’s different about projects now is this: the easy work is done. Waterfall only works on shorter, smaller, and not-too-complex projects. You can make it work on longer, bigger, and complex projects–it’s really hard to do so, but you can. Now, if us mortal folks are faced with a longer, large, and more difficult project, it makes sense to use the tools (including the lifecycle that fits the context best) to make the project work.
I don’t understand why anyone wants to know when some practice or approach started. Assume it was a long time ago. (I used continuous integration at university, because there was no other way to know if what I was writing was any good. I first paired in 1982. Kicking and screaming, but I did pair. I first used version control in 1976 when I worked with another developer.)
Does it really matter when a practice started?
The real question is this: Is this approach or practice a good idea for my project? That’s a useful question. Ask it.
