Hi – This is Irfan, Director of the ACE Team. Some of you may have come across Abu’s recent blogs on Performance Development Lifecycle for IT (PDL-IT), I thought it would be useful to shed some light on the history of the performance side of the ACE Team as well as discuss what led to the creation of PDL-IT. As mentioned in my earlier blog, the ACE Team was originally formed as a dedicated performance team back in 1999 and we’ve been going strong in the area of performance for 10 years. Prior to ACE’s existence, centralized performance testing in Microsoft IT was conducted by the SAT (Software Acceptance Team). SAT was formed in 1996 and it’s primary goal was to review operational specifications of LOBs and test those applications against those specifications to ensure they were ‘ready’ and ‘able’ to be released into production. Part of the testing conducted by SAT was load testing. Testers would review the operations specs where the business would have articulated the anticipated user load and from there tools/scripts would be put to use to simulate that load. SAT remained in existence until 1999 at which time the testing they were conducting was rolled back into the development teams, however the benefits of a dedicated performance team stood out and those individuals who were driving load testing were spun off to create ACE. So that was the Cliff Notes version of ACE’s history with performance testing, now moving onto PDL-IT…..
PDL-IT is a direct result of best practices and standards that we’ve compiled over the past 10 years. Through PDL-IT we’re able to build into the Software Development Lifecycle the necessary performance testing milestones needed to reduce the risk resulting from costly IN PRODUCTION performance issues. As is the case with security issues, if you are able to uncover problems early in the development lifecycle the cost (in terms of man hours and budget) to fix issues is dramatically reduced. That’s why you’ll find that through PDL-IT it calls for the engagement with application teams as earlier as the envisioning stage. That’s when the business owners are sitting across the technologists describing the business objectives they’re trying to hit. Part of that discussion MUST be about expected user loads thus providing context around desired performance goals. The other reason behind PDL-IT was a more simplistic one, that was to put a ‘name’ to our methodology. Its much easier when talking to application teams to say “refer to PDL-IT” Vs “our team’s methodology”. I just finished recording a video that delves a bit deeper into PDL-IT, if you’re interested in learning more about the methodology you can view the video here. Hopefully between Abu’s blog and my video you have a better idea of PDL-IT, we do plan on publishing more information on the methodology but meanwhile we look forward to your comments and questions.