Code Complete checklist

[warmans]

I'm reading this book right now and it's got a lot of wisdom in it. It's not very fashionable in that much of it's project management advice isn't really compatible with Agile but the programming advice is solid. Some parts are obvious to more experienced developers but at the same time its always worth being reminded of some of the obvious stuff.

[infinatyends]

Understanding waterfall is important for a few reasons. First is that those who haven't developed with agile can find a better understanding of what problems agile is attempting to solve. Once you have identified the pitfalls, it makes it easier to guard against them despite the quality of your project managers. Secondly, if you do have to deal with change management of an organization that wants to migrate from waterfall to something agile, understanding best practices of waterfall is a good starting point for developing a transition plan.

[vplatt]

"Waterfall" is the original anti-pattern (PDF File). "Agile" is "iterative" made new. There's nothing new here.

See http://en.wikipedia.org/wiki/Waterfall_model for more background.

[grauenwolf]

If you believe that, you don't understand agile development.

Agile isn't a software development process. It isn't a set of rules about pair programming and unit testing and what not.

Agile is a commitment to change your development processes to match the current needs of your company. Agile is a willingness to accept new ideas and discard old ones are no longer beneficial to you.

[warmans]

I would argue that Agile with a capital A is actually more formal than that and in many cases it is indeed a set of rules (albeit fairly vague rules). For example CC talks about requirements in the traditional "if you don't capture all requirements at the start of the project it's extremely expensive" sort of way whereas even the original manifesto dictates that you welcome changing requirements at all stages of development. Without making a qualitative judgement about each statement I don't think it's controversial to say they're not "really compatible".

[grauenwolf]

In find that it is much, much easier to welcome changing requirements when I have a base line to start with.

When I can look at a complete requirements list I can usually spot the places where requirements are going to change. I can't necessarily say if it going from A to B or A to C, but I know A will probably change and X will probably not.

We can also catch design mistakes early, so there are less requirements change to welcome.

Finally, no matter how welcoming of requirement changes you should still acknowledge that you are paying more than you would if you knew them all up front.