While exploring the use of code metric tools for our current architecture, I came upon this fantastic intro to NDepend, by Andre Loker - an absolute must-read:

http://blog.andreloker.de/post/2008/07/08/NDepend-code-metrics-at-your-service.aspx

Google on static vs dynamic URLs

Google have just posted to their Webmaster Central blog about the use of URL rewriting to convert dynamic URLs to static ones, incorporating querystring parameters what the user and browser see as a folder structure, eg domain.com/products/books/193872. They make some excellent points about the difficulty they face in knowing which part of such a URL is actually dynamic, and which isn’t - a very interesting read

For more info on URL design, these ALA articles are brilliant:
Slash Forward
How to succeed with URLs

I just took it - why don’t you?

A List Apart Survey 2008

Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement. XP and OpenUP support changing requirements during the iteration if you wish to work that way, although doing so may force you to sometimes move some requirements to the next iteration to make room for new requirements introduced during the current iteration. Both approaches are perfectly fine, you just need to choose the approach which makes the most sense for your situation.

Agile Requirement Change Management by Scott W. Ambler

Message passing is a huge part of efficiently written software. With all the modular pieces buzzing along, doing their own thing, it becomes important that they have some mechanism to communicate with one another. Many programming languages have some level of built-in support for passing information back and forth between chunks of code, and it is often best to leverage these facilities. By mapping out the communication paradigm before a single line of code is written and keeping consistent throughout the whole application, the programmer saves him- or herself the trouble of inventing a new set of messages each time an additional module is added.

The notion of communication here applies both between modules, or teams, which may constantly interact with each other and require well-defined APIs for interaction, and for more asynchronous, interrupt-driven messages, which may better be handled by an event-based notification system. In a corporation, top-down information, such as announcements or strategic direction, should be able to easily be transmitted down the corporate hierarchy (this is often handled in meetings and email lists); equally important (though much harder to implement appropriately) is for messages coming from the lower levels to be heard at the very top without having been distorted or in any way compromised along the way.

A very interesting read from Dan Greenblatt: Thoughts On Software Architecture and Corporate Structure