moving targets

Another quick turn-around project... a project without a definable scope - no parameters, just a vague idea of what somebody thinks somebody else wants.

I had a cocky, pain-in-neck CE student a few years ago. He liked to question everything, which is exactly what students should be doing - that's not what made him a pain. He was lazy, didn't do his work, and slacked miserably on his collaborative project. One day in class we were reviewing documentation methodologies and some basic aspects of systems design (you know, the whole needs analysis/requirements gathering thing before you start really doing anything). Somewhere in the middle of the discussion, Wise Guy says, "We really don't need to know this stuff. Agile development is now. We just do it. We don't waste time with documenting requirements, we just do it."

My reply to Wise Guy's outburst included something about the need to know what you're doing before you just do it. I noted that one of the problems I encountered with Agile development (in my case it was a software development company that had adopted extreme programming) is that it assumes the client is willing to and is capable of making modifications to the design on the fly, at the point of unit testing. In my particular case, this assumption carried a tremendous amount of overhead for the development staff. When the client proved to be unwilling to be an active participant in the development of their product (I gave you money, now you give me what I paid for), the development staff had no documentation to fall back on - no record of analysis, nothing that clearly identified for anyone what problem was going to be solved and how best to solve it.

It sometimes seems like business in academia is conducted like Agile development. I'm still struggling with this 6 years in.