eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers (Microsoft .NET Development Series) (Paperback)

by Neil Roodyn (Author)

Editorial Reviews

From the Back Cover

"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.

© Copyright Pearson Education. All rights reserved.

Excerpt. © Reprinted by permission. All rights reserved.

Setup

If you are a developer using the .NET Framework, or if you are thinking of using the .NET Framework, then this book is designed for you.

I have used the material in this book in training courses for a number of years. The experience of the students in these courses range from the .NET novice to the experienced developer, but everyone benefits from the exercises. The novices learn about .NET Framework development while at the same time learning good development practices. More experienced developers work through the exercises more rapidly and are able to focus on the techniques being taught.

This book introduces you to practical techniques that you can use to improve your software development abilities. These techniques have been heavily promoted in the last few years as practices in a set of methodologies. The methodology from which I draw most of my experience is eXtreme Programming (XP)—hence the title of this book.

Throughout the book, you will find highlighted text accompanied by icons. The icons are there to differentiate the type of section. The three section types you will encounter are as follows:

Story: These are tales from my experiences in developing software and training development teams.

Discussion: These are conversations taken from the real-life experience of working with development teams.

Future Tools: This section features plans for future versions of Visual Studio.

What Do You Want?

When you are developing software, what do you want?

• Fewer bugs

• Greater predictability

• More time (to do what you want)

• Satisfaction that you've done a great job

• Happier customers and managers

This book introduces you to a set of techniques designed to put you on the road to reach your goals.

The practices examined throughout this book are taught mainly through hands-on exercises. I strongly believe in learning by doing, and, after all, this is about programming in an extreme way.

Terminology

XP refers to a collection software development practices and is sometimes called referred to as a methodology. However, there is more to XP than just the practices and the values. XP creates team camaraderie. XP produces happy customers. Just following the practices and knowing the values isn't XP. The practices and values provide a vocabulary to discuss and enact the development of software. XP is about loving the creativity of software. XP teams embrace the changes during the development. XP teams want to ship great software products. XP helps to create a team that has the same goals. XP teams achieve their goals.

.NET (pronounced "dot net") is the colloquial term given to the Microsoft .NET Framework. In this book, I discuss software development using the .NET Framework. Developers using the .NET Framework have adopted the new technology incredibly fast. There is more to .NET development than just the framework and the tools. Developers using the .NET Framework love the product and what it can achieve. The opportunities provided by the .NET Framework have excited a large percentage of the development community.

eXtreme .NET is the term I have given to developing software using the .NET Framework and some (or all) of the XP practices. eXtreme .NET teams create high-quality solutions in short timeframes. They embrace the spirit of XP along with the excitement of developing with the .NET Framework. Above all, eXtreme .NET teams have an incredible passion for creating great software.

This book introduces the techniques used by eXtreme .NET developers.

How I Got Here

In the beginning, I just wrote code. I programmed in BASIC and then in 6502 assembler. Then I learned C, 8086 assembler, and then Pascal. I started to understand some of the issues involved with functional programming and then procedural-based development. Most of the projects I did were small, achievable by me or with just one other programmer. The communication channels were limited, and we got software shipped. I was often a guy alone in a room.¹ My bosses at the time often let me work from home or on my own hours. Often I would start early, have a long lunch, take a nap in the afternoon, and then program until midnight. Life was good, and I worked on some really cool software. Some of this software still ships.

Then in 1991, I joined my fist big software team; there were five of us! I was the last to join the team. The project was already in full swing, and it was chaos. I was confused, afraid, sad, and mad all at the same time. The code in the source-code control database didn't all compile. There was no standard coding convention; each programmer coded with a different style. There was no form of testing. We had no idea when the system would be finished. The tasks were handed down to me as I finished the previous one. I had very little idea where I was going. We were programming in C++, and this was only my second C++ project. I was afraid that the lack of object-oriented (OO) programming in the project meant that I did not understand what OO was really about. One month after joining the team, I started to raise these issues. There was a lot of struggle and internal debate, especially about the little things such as where the curly braces should go!

Eventually we got the system in a state where the code all looked pretty much the same. We reached a point w