IT is just IT

This list describes the reading program a software developer needs to work through to achieve full professional standing. The plan described is a generic baseline plan for a software professional who wants to focus on development. Introductory Level To move beyond "introductory" level, a developer must read the following books: Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, MA: Perseus Publishing, 2001. Bentley, Jon. Programming Pearls, 2d ed. Reading, MA: Addison-Wesley, 2000. Glass, Robert L. Facts and Fallacies of software Engineering. Boston, MA: Addison-Wesley, 2003. McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. McConnell, Steve. Code Complete, 2d ed. Redmond, WA: Microsoft Press, 2004. Practitioner Level To achieve "intermediate" status, a programmer needs to read the following additional materials: Berczuk, Stephen P. and Brad Appleton. Software Configuration Manag

Here is a common question I get regularly. In this case it was Howard, a co-worker from the UK: “Probably a dumb question but...how do you define scope yet remain agile?  Is it woolly wording, do you define it using some kind of abstraction or do you define in terms of number of iterations? The key being that, in my experience, most people what some idea of what they're getting up front, yet in remaining agile we want to defer that sort of decision until later.” This is not at all a dumb question because it identifies the key difference between agile and traditional project delivery. Here is my response to the questions. In my projects scope is a matter of defining this at the right abstraction level, or maybe more precise defining it without much detail. First thing you need is an concrete idea about the project’s scope boundaries. You can use the business case and vision for this purpose. They should provide the constrains with respect to for example business processes to suppo