 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Microsoft .Net Development News > Sam Guckenheimer on software engineering and Visual Studio Team System |
| |
|
|
|
|
| Microsoft .Net Development News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||
Many books have been written about software engineering processes, and they take many forms. Some introduce philosophical matters, and to good effect. But with others, you may wish the writers did not fancy themselves as philosophers at all. On the opposite end of the spectrum from the philosophical titles are the instruction manuals that tell you how to use a tool to effect -- though their usefulness seldom goes beyond the specific tool the authors cover. With these, you may wish for a bit more of background or overview -- philosophy, if you will. Other issues for software engineering books are depth (some dwell on minutiae, some gloss over major concepts) and focus (there are a lot of disciplines covered within a full development team -- you can satisfy one narrow audience, but freeze out the rest). Sam Guckenheimer's Software Engineering with Microsoft Visual Studio Team System, with Juan J. Perez, turns out to be an amazing addition to the software engineering library. Its focus on acquainting people with Visual Studio Team System, and its size -- 255 pages -- would not naturally tag it as extraordinary. But Guckenheimer's grasp of software engineering is firm, and with this book he has managed to be brief without being flip. Of course, Microsoft Group Product Planner Guckenheimer's real baby is the software and not the book. He joined Microsoft from Rational in 2003 to work on what is now Visual Studio Team System. But he has produced a book to be proud of, while writing one designed for team members to swap around. A developer could lend it to a manager, or vice versa. He also designed a book to be as brief as possible. This is one that can be read over the course of a weekend or a cross-country plane flight. It is not a book for developers or architects if what they want is something that can't be understood outside of their own discipline. Like the tools it describes, the book is about the team. Don't let its brevity deceive you as to its value. Certainly, there must have been a major effort on the author's part to be concise where others would expound. (This brings to mind the saying attributed to Pascal: "If I had more time, I would have written a shorter letter.") Yes, the book is basically about the Visual Studio Team System, but there is enough plain good engineering sense in here to entertain at least a few people that will never work with this Microsoft software. Guckenheimer has a gift for bringing out the interest in mundane matters. His descriptions of how to troubleshoot software projects are to the point, but colorful. Itemizing work, metrics, prioritizing bugs, top-down and bottom-up design methods -- these all come in for interesting treatment. TheServerSide.NET's Jack Vaughan recently spoke with Guckenheimer. Q: Let's talk first about the product. What was the team that made Team System trying to do? A: We saw there was huge opportunity to make lives better for millions of people who are working in IT. We looked at where the [life-cycle tools] market had been. It was very much for a "two-sigma" crowed, people who invested a lot in tools, who went to conferences like OOPSLA, who were willing to put up with pain. The tools were much too hard to use. They were often very limited in terms of the workflow. We had the notion we could take tools that had been developed by Microsoft in-house and productize those with the type of approachability Microsoft puts in its products. Q: And this was to include the broader team, including project managers .. and the data reporting would be more sophisticated .. A: We found that project managers spent 40 hours a week cutting and pasting. We tried to take that down to maybe a couple. Instead of having tools that worked in different ways, we said, 'We will instrument all of the activities and put them into a multidimensional warehouse.' We have been doing this with supermarket data for years. Q: So what was the spec when you set out to write the book to accompany all this? A: The largest challenge was that I set a couple of design goals, if you will, for the book. One was that it would be valuable for an individual team member such as an architect, or manager, and at the same time it could be being something that a person would want to lend to their boss. So it was intentionally aimed at multiple roles and competencies in the team, and had to speak to both. I am not trying to take a way from the 'depth' books. But what happens with the depth books, they are exactly appealing to people with the competency that want to go deep. But they don't provide the [collaborative communication] that works across disciplines for the team. Q: The connection to deployment seems to mark something fairly new in life cycle development systems? A: We have tackled two large problems. The most important one we think in architecture is getting compilable, testable, executable baseline architecture as quickly as possible. The second problem we address with Visual Studio Team System is the pain that so many programmers find after the software is finished and ready to deploy. So we introduced Design for Operations, where you can validate the design for the application against the data center, just as the data center is configured, and long before you go into the detailed coding. The intent is to eliminate the long and laborious backend time as people try to figure out what is the difference in the deployed system and the one they built. [A goal was to create a system that helps you] to move as soon as you can from an intent to a working and testable representative system that may be not be wholly filled out as the agile method calls for. A lot of architects say architecture is much more than that, and they are right. We don't try to solve all of architecture issues. There is a fair amount of legitimate debate on how to do that. What we did target was getting to a baseline [design] quickly, and using it for iterative, incremental improvement. With every iteration you can build out functionality, and address problems up front that, if left there, would delay or even defeat deployment. The architect is typically a mentor or a leader providing the guidance and vision here. The architect can assure that the system will deploy as designed, and get a testable baseline at the start. Then at the various iterations, you end up with a much smoother path, and far less contention, and, frankly, less of the blame game.
|
|
|
|
|||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
