Software Engineering, Project Management, and Effectiveness
When a patterns & practices deliverable would be ready to ship, our General Manager (GM) would ask me to sign off on the performance and security. I would usually be pulled thin so I needed a way to scale. To do so, I created a small checkpoint for performance and scalability. The checkpoint was simply a set of questions that are a forcing function to make sure you've addressed a lot of the basics (and avoid a lot of "do-overs"). Here's what we used internally:
Checkpoint: Performance and Scalability
The checkpoint helped the engineering team shape their approach and it simplfied my job when I had to review. You can imagine how some of these questions can shape your strategies. This is by no means exhuastive, but it was effective enough to tease out big project risks. For example, do you know when you're software's going to hit capacity? Did you completely ignore the customer's practical environment and use up all their resources? Do you have a way to intstrument for when things go bad and is this configurable? When your software is in trouble, what sort of support did you enable for troubleshooting and diagnostics?
While I think the original checkpoint was helpful, I think a pluggable set of checkpoints based on application types would be even more helpful and more precise. For example, if I'm building a Web application, what are the specific metrics or key instrumentation features I should have? If I'm building a smart client, what sort of instrumentation and metrics should I bake in? … etc. If and when I get to a point where I can do more checkpoints, I'll use a strategy of modular, type-specific, scenario-based checkpoints to supplement the baseline checkpoint above.