15 percent of the resources dedicated to Chicago or 85 percent of the resources on Office96. See what we did there.—Resource allocation for the parallel releases, as marketed internally
"Picking dates with resource levels set is the first rule of shipping." This philosophy was novel at the time. Much later on a book was written by Ram Charan and Larry Bossidy named"Execution" which laid out the need to align resources with strategic priorities. That is exactly what this philosophy did.
It is also interesting to think about time as another dimension of resources. Once the ship date is set laying out the engineering work in ever more specific iterations is required to arrive at a project that can execute on its expectations. The first level of iteration was defining a set of engineering milestones followed by integration and stabilization periods. Working recursively, milestones themselves were a set of features followed integration and stabilization. An individual feature was a set of tasks followed by integration and stabilization. For the schedule to be believable, tasks had to have a single developer and last no more than two days. When planning, all features were recursively subdivided until this standard was met.
In today's jargon, the schedule became a work or burn-down list sorted by priority of task and feature with estimates allowing the team to know roughly what tasks would be complete in what period of time. The development leads of each feature team were responsible for standing up their teams once a week to check off work completed and update estimates based on learning. This allowed the schedule to become more accurate as time went by as the team learned and technical issues were identified.
It is confidence in the above planning and execution framework that allowed us to think we could get away with something as audacious as 12/24.
There was always out of the box thinking/pressure from BillG and NathanM for the 48/60 work as well. We understood this but were never confident we could do it. But sometimes things were engineered that way. 32 bit support is a good example, where app teams had a couple developers outside of the execution framework of Office 4.x porting the 16 bit code to 32 bits, identifying the problem areas, and building toolsets that could then be leveraged more broadly. That was critical work that enabled Office 95's team. It was the learning from these folks about the challenges of 32 bit app performance that contributed to the 12/24 thinking. Some of the performance work just couldn't be done on the Chicago timeframe. It wasn't the major reason for 12/24, but it was one part.
The first 32 bit Office (just XL and Word) was Office for Windows NT was released before Office 95 (Intel, DEC Alpha, MIPS, and Power PC versions if my memory is correct) which made the 94/96 releases easier. At least is was mostly 32 for Excel. DuaneC could go into the details around the recalc engine.
As for the Windows Logo, I seem to remember a GPM saying that, "What the Windows team doesn't understand is that we (Office) are the Windows Logo." :)
Hi Darrin...yes it was (I might have mentioned that). The first version of Office for 32 bits was for NT and had 32 bit Word and Excel, but 16 bit powerpoint (and 32 bit MOM!) KirkG and a couple of others did the dev porting work, and as you said it gave us confidence and also removal of any remaining ASM and pcode stuff. It was super helpful from a benchmarking perspective as I will mention in the next chapter. Between your team and Peggy's I don't recall specifically the split of tracking and doing the release. It taught us that the apps got much bigger even though documents did not get longer :-)
I came in finished out the NT XL release and worked with Ebbe Altberg (who I believe had an email address of just Ebbe) as the PM on the Word side. I think we tried to get agreement on what was right to do and then convinced the rest of the teams to go along once Word and XL agreed. I believe Peggy helped to pull it all together.
Yes it was bigger. I believe the recalc engine for the release was more of a "C" port rather than true assembly, so that was larger. DuaneC would know the details.
For NT XL5 the calc engine was using C libraries on all 4 platforms. Patrick Ho and John Kruper did most of the porting work. DuaneC and JohnK rewrote the calc engine in native assembly for Excel95.
By fortunate coincidence, as you have been writing these I have been teaching summer classes on C++ and Microsoft Office at a local community college. If you do not have any objection, I would like to send my students a link to read this entry and also #10 (Our First BillG Review) as I think these two entries will reinforce some concepts I have been trying to bring to them -- particularly the messy evolution of C++, OOPaholism, and the joys of binary files (last class we did a hex dump of a xls).
"Picking dates with resource levels set is the first rule of shipping." This philosophy was novel at the time. Much later on a book was written by Ram Charan and Larry Bossidy named"Execution" which laid out the need to align resources with strategic priorities. That is exactly what this philosophy did.
It is also interesting to think about time as another dimension of resources. Once the ship date is set laying out the engineering work in ever more specific iterations is required to arrive at a project that can execute on its expectations. The first level of iteration was defining a set of engineering milestones followed by integration and stabilization periods. Working recursively, milestones themselves were a set of features followed integration and stabilization. An individual feature was a set of tasks followed by integration and stabilization. For the schedule to be believable, tasks had to have a single developer and last no more than two days. When planning, all features were recursively subdivided until this standard was met.
In today's jargon, the schedule became a work or burn-down list sorted by priority of task and feature with estimates allowing the team to know roughly what tasks would be complete in what period of time. The development leads of each feature team were responsible for standing up their teams once a week to check off work completed and update estimates based on learning. This allowed the schedule to become more accurate as time went by as the team learned and technical issues were identified.
It is confidence in the above planning and execution framework that allowed us to think we could get away with something as audacious as 12/24.
There was always out of the box thinking/pressure from BillG and NathanM for the 48/60 work as well. We understood this but were never confident we could do it. But sometimes things were engineered that way. 32 bit support is a good example, where app teams had a couple developers outside of the execution framework of Office 4.x porting the 16 bit code to 32 bits, identifying the problem areas, and building toolsets that could then be leveraged more broadly. That was critical work that enabled Office 95's team. It was the learning from these folks about the challenges of 32 bit app performance that contributed to the 12/24 thinking. Some of the performance work just couldn't be done on the Chicago timeframe. It wasn't the major reason for 12/24, but it was one part.
The first 32 bit Office (just XL and Word) was Office for Windows NT was released before Office 95 (Intel, DEC Alpha, MIPS, and Power PC versions if my memory is correct) which made the 94/96 releases easier. At least is was mostly 32 for Excel. DuaneC could go into the details around the recalc engine.
As for the Windows Logo, I seem to remember a GPM saying that, "What the Windows team doesn't understand is that we (Office) are the Windows Logo." :)
Hi Darrin...yes it was (I might have mentioned that). The first version of Office for 32 bits was for NT and had 32 bit Word and Excel, but 16 bit powerpoint (and 32 bit MOM!) KirkG and a couple of others did the dev porting work, and as you said it gave us confidence and also removal of any remaining ASM and pcode stuff. It was super helpful from a benchmarking perspective as I will mention in the next chapter. Between your team and Peggy's I don't recall specifically the split of tracking and doing the release. It taught us that the apps got much bigger even though documents did not get longer :-)
I came in finished out the NT XL release and worked with Ebbe Altberg (who I believe had an email address of just Ebbe) as the PM on the Word side. I think we tried to get agreement on what was right to do and then convinced the rest of the teams to go along once Word and XL agreed. I believe Peggy helped to pull it all together.
Yes it was bigger. I believe the recalc engine for the release was more of a "C" port rather than true assembly, so that was larger. DuaneC would know the details.
For NT XL5 the calc engine was using C libraries on all 4 platforms. Patrick Ho and John Kruper did most of the porting work. DuaneC and JohnK rewrote the calc engine in native assembly for Excel95.
By fortunate coincidence, as you have been writing these I have been teaching summer classes on C++ and Microsoft Office at a local community college. If you do not have any objection, I would like to send my students a link to read this entry and also #10 (Our First BillG Review) as I think these two entries will reinforce some concepts I have been trying to bring to them -- particularly the messy evolution of C++, OOPaholism, and the joys of binary files (last class we did a hex dump of a xls).
What fun! Please do share with my regards to the class!