Brandon McMillon writes on doing it right. (Thanks to Alfred Thompson for the link.) He doesn't touch on the agile side of software development - although I can guess his opinion by his planned article "Pair Programming is for Morons" - and so the article has a lot of stuff about Objectives and Requirements and Spending Design Time Up Front. The tricky bit about commenting on this sort of article is that I don't really disagree; his straw man comparison is that one group who just goes off and starts coding so they can get it done faster. That is bad. He does mention how getting sign-off and buy-in from users and stakeholders is valuable, and here's where we might differ: getting this sort of data is important throughout the life of the project, not just somewhere near the front. Because once a user gets some working software in his her hands, she's immediately going to have ideas to improve it, and they'll probably be good ones. So, while it's nice to do some designing up front, it's more important to have your code in a state where you can make changes easily and quickly, to respond to the inevitably changing user requirements.
What I have written here is short, and therefore oversimplifies the many issues. But the full range of agile practices can answer most objections, in my experience.
I think you must also give clear content of dumbest.
ReplyDelete