When people talk about “improving” software methodology, they rarely talk about tradeoffs. Requirements freeze, for example, runs the risk of delivering exactly what the customer asked for – and not what he needs. Concrete, detailed estimates take a considerable amount of time to create, and that’s time that could be spent writing code or executing tests. M. Heusser discusses the tradeoffs and choices you’ll have to make when the goal is improving (or even initially developing) your methodology.
Methodology Design: the Way We Do Things Around Here
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Well, the guy talks about tradeoffs as if they’re never discussed. They are, but maybe in just a more informal manner than he would like – “well if we do this, then that cuts down on the time we can do this…”.
He seems to endorse agile development, which I agree works for many projects, but I don’t think you can apply to all projects – life and death, mission critical software, extremely large software systems…. But we’re pretty informal for the projects we work on. We write new and/or modify new modules that fit into the system already, and sometimes decide on new interfaces we should write to.
Just do whatever works for your group and don’t get caught up in the hype of any supposed silver bullets.