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

InfoQ have a fascinating Q&A session with leading technologists about their preferred manners of ensuring their infrastructures remain performant under high traffic.

InfoQ: Scaling and Performance tuning is often seen as a fire-fighting activity; it’s all about fixing the problem right now. How would you go about tracking performance regressions over a mature codebase?

Matt Youill, Chief Technologist at Betfair: I think these are only truly detected once the application is live. Ensure that an application is partitioned effectively and deploy it onto one server in the live environment. If it looks good, deploy it onto another, and then another, and so on. Make sure that you invest in effective monitoring and measurement infrastructure to catch performance issues early in the rollout process.

Don’t try and catch performance issues before you deploy. You won’t be able to recreate the conditions that exist in live, and consequently you won’t get realistic dependable measurements.

http://www.infoq.com/articles/scalability-panel

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