Saveen pointed me at these blogs about product development at Adobe. Pretty interesting reads, sounds a lot like things around here:
The note at the end of the second one (“In reality, what it all comes down to is testing.“) really resonated with me. At the end of the day, code is just code and many things can be done, given enough time to write and test it.
This reminds me of a few years ago, when I’d spent the last 6 months of my working life investigating the myriad of things necessary to do in order to get Exchange 2000 to run on Windows 2003. We were trying to make it work in SP2, and kept uncovering problem after problem. I was in the middle of a lot of those discussions because OWA had one of the highest impacts due to its usage of IIS, and I was the lucky owner for figuring out the variety of problems in that area. With the security changes in Windows 2003, there were a lot of implications for large applications like Exchange related to usage of the metabase, DNS, AD, etc – things like deprecated insecure APIs, bug fixes that changed default return values on API calls to be more secure as well as new features added to lock down the server (the ISAPI restriction list and IIS6 mode were two of the biggest ones that I spent a ton of time working through).
And worse yet, the design of those security features was still in flux, so in at least one case (the original ISAPI restriction list design), we wrote some code to handle the new security feature, and then the design changed entirely, and so we had to snap to the new design. I was supportive of the design change, however, because the updates to the design clearly made for a better admin experience. (that didn’t mean I didn’t kvetch at the IIS team quite a bit though.. During this timeframe Windows 2003’s ship date also pushed back a bit so that they could have more time to work on the security changes.
At any rate, throughout the process of this investigation we kept uncovering more and more issues, until it came to a point when we knew we had to ship, we had to get SP2 out to our customers and couldn’t delay any longer. So we made a call to cut the effort, postpone supporting Windows 2003 to the next release (then codenamed Titanium, eventually called [shockingly] Exchange 2003].
At any rate, one day I was sitting in my office, and my phone rings. My caller ID says it’s Paul Flessner calling me (then the SVP over Exchange & SQL). Let’s just say that it is not a normal occurrence for a leaf node PM to get calls from SVPs. “Hi KC, this is Paul Flessner.” (I said something like “Uh” in response). He proceeded to drill me on why we couldn’t make Exchange 2000 SP2 run on Windows 2003 (then codenamed Whistler), like he was testing my ability to answer his technical questions but because I’d been so deep in the area for so long I apparently handled it fine. I then found out that our release manager was standing in his office – she had just relayed the decision to him, and when he started questioning her about the details, she passed the baton my way, lucky me. I don’t remember much else of the conversation except that at one point he said “You’re telling me that it’s not possible to ship Exchange 2000 SP2 on top of Whistler?!” and I said “Well sure, given enough devs, testers and time, we can do it.”
In the year or so after we made that decision, I had countless discussions with customers who thought we made the decision for fiscal reasons, we were just trying to squeeze more money out of our customers, etc etc… let’s just say that it’s really frustrating to have your customers think you’re evil. I ended up writing a short whitepaper detailing the technical reasons, which eventually got marketingized and released here.
One of the reasons I like blogging so much is that it’s so much easier to explain the behind-the-scenes operation… at the time this was going on I didn’t have (or rather, didn’t know I could have 😉 a forum to broadly communicate things like this.