Pierre-Emmanuel Dautreppe

 eXtreme .NET

Introducing eXtreme Programming Techniques to .NET Developpers

By Dr. Neil Roodyn

Summary of the editor

'At last, somebody has introduced eXtreme Programming techniques to the world of .NET! Through enjoyable writing and tons of hands-on exercises, Dr. Neil explains how to use the best techniques from eXtreme Programming to vastly improve developer productivity within the .NET Framework.'

--George Bullock, Program Manager, Microsoft Corporation

eXtreme .NET shows developers and team leaders how to incorporate eXtreme Programming (XP) practices with .NET-connected technologies to create high-quality, low-cost code that will build better software. This practical, realistic guidebook systematically covers key elements of XP methodology in the specific context of the Microsoft .NET Framework, Visual Studio .NET, Visual C#, and related Microsoft .NET-enabled applications.

Leading .NET and XP mentor Dr. Neil Roodyn covers planning, task definition, test-driven development, user interfaces, refactoring, spiking, pair programming, and much more. Dr. Neil offers field-proven advice for everything from automating builds to integrating third-party libraries. He also incorporates valuable exercises and presents a start-to-finish case study that shows exactly how XP and Microsoft .NET interoperate throughout an entire development project. Coverage includes

• Where to start if you've never used XP or other Agile methods before
• Pair programming: Turning .NET programming into a collaborative game
• Test-Driven development: Making sure your .NET code works as intended while it's easiest to fix
• Refactoring: Organizing your .NET code to improve flexibility and enable changes more readily
• Continuous integration and automated build/test: Enhancing quality in distributed, component-based systems
• Spiking: Using rapid experimentation to validate your expectations about behavior in the .NET Framework
• The importance of customer input to successful projects
• How to test .NET user interfaces and third-party libraries

The Microsoft .NET Framework is today's most productive development platform. XP represents a fundamental breakthrough in building higher-value software. Combine them: transform your team into an eXtreme .NET team that can accomplish more than ever before. This book will show you how--starting with your very next project.

Dr. Neil Roodyn has been actively involved with eXtreme Programming since 1999, and founded Sydney's eXtreme Programming Activity Club (SyXPAC). He has helped drive the adoption of the .NET Framework in Australia through his work as a project leader, consultant, instructor, and mentor. His clients have ranged from Microsoft to Rogue Wave and he has helped launch several software startups. Dr. Neil holds a Ph.D. from University College London where he specialized in software architectures for real-time systems.

My criticsm and comments

It was more than 2 years I was working in an XP team when I read this book. As a consequence, I was already having my habits (whatever they were good or wrong) and my team was working in a smooth way, living on its certainties. We had learned XP, clearly adopted it, and for sure adapted it.

It's also a long time that I implement design patterns. I usually adapt them or combine them so they better stick to my functionnal and implementation need. However, I like to go back regularly to the GOF to re-read the theory of the pattern(s) I want to put in place. What for? Just to get back to the definition and to appreciate more in detail any delta I was thinking to do. After that, maybe I will not change my implementation idea but at least I had been focused on all differences between my idea and the theory, and had forced myself to wonder why I was thinking to do that or that change. It helps me doing my job in a more clever way, letting me ask the "Why" towards my solution.

I see this book in the same way. It has allowed me (forced me?) to go back to the definitions, and most of all to the definitions given thru examples. Clearly, it made me look deep at each step of our XP stack to see what we were doing, if it was working good or not, if such or such difference was needed or not. It does not mean that we have drastically changed everything after that but clearly the interrogation is the first step to do before taking actions, and these examples gave me some directions where I wanted to go.

How does it work in practice? The author present us a small XP team: a few (named) characters having all their own personality and domain of competence : from the client, including the expert, to the stressed guy seeing insurmountable difficulties in all places. (Come on, we have all met a guy like this. Maybe yours won't scream "Panic !!" each time, but it will for sure tell very often "Gonna be hard", "It's not won in advance" or "I have no idea of how we can do that". Please... just come with positive mood, and with solutions... It's in moment like that, that I like the most the Shaddock philosophy...)

We are following this team among all the phases of a project development: analysis, development, refactoring, spiking, planning game, ... Each "act" will be described with some team dialogue, to put these personnages in action. And in most of the parts, some exercices and code example really place us as privileged spectators, in the center of the arena.

A sentence to remember?

Two in fact. First of all this book reinforce the fact that XP (and agile methodologies in general) will better fit to a team composed of mature developpers, with solid notions of simple design and conceptions. Did I said simple? This is the other fact I like to mention when I can.

"Simple does not mean easy. Developpers who are starting out often misinterpret this as "Do the easiest thing you can possibly do." This is incorrect; simple is often a lot harder to achieve than complicated. [...] The switch statement is easier to write, but the polymorphism provides a simpler solution."

The last word? This is an easy reading book, done in a clever way, didactic and fun, but highly serious at the same time. A "must-read" book to place in the hand of all XP team (beginners or not) and to be seen as an external third-eye. My only real criticism? Well... it has not been read by all of my team members. But can we really blame the author?

Want to find more about the books I have read ? Go to my bookshelf to find the few criticism I have already made !

 The graph showing the evolution of the build duration (in blue) compared to the evolution of the number of tests.

You can parameter different tresholds to specify which builds you want to see appearing on this graph

 Some data of the Code Coverage metric : global and individual percentage.

Some conditional formatting will help finding quickly the trend and some code coverage problems.

 The graph displaying the evolution of the overall code coverage.

Another graph will also show the individual code coverage evolution.

 The graph showing the distribution of the cyclomatic complexity among the methods.

You can also see in red the line of slope "-2" which is the empiric limit between projects trening to simplicity (below) or trending to complexity (above).