From Book News, Inc.
Assuming a familiarity with C#, this book shows how two developers can work together to solve problems and write better code, and how to break work down into small tasks and simplify the code. It emphasizes the importance of testing, and examines the tools available for automating the compilation and testing of code. The final chapter walks through an example project for adding an alarm to the desktop.Copyright © 2004 Book News, Inc., Portland, OR
From the Back Cover
"This series is a great resource for developers using the .NET Framework and Web services. It covers all the bases from reference to 'how-to.' The books in this series are essential reading for developers who want to write solid managed code."—John Montgomery, director, Developer Platform and Evangelism Division, Microsoft Corporation
"This series is supported by the leaders and principal authorities of the Microsoft .NET Framework and its languages. It has an author pool that combines some of the most insightful authors in the industry with the software architects and developers at Microsoft."—Don Box, Architect, Microsoft CorporationThe First Start-to-Finish Guide to eXtreme Programming in Microsoft® .NET Environments
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 .NET Framework, Visual Studio .NET, Microsoft 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 .NET 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. He has spent more than a decade working with leading-edge technologies, from COM to today's newest mobile platforms. He holds a Ph.D. from the 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.
SetupSetup
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.1 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 where we could compile the entire code base every night. I was realizing the importance of development practices to the team.
For a few years, I worked with a couple of teams. I helped these teams implement what I considered to be crucial aspects of the development process. In 1995, I became involved in my first start-up company. All the developers were younger than I, and by virtue of my age I was looked up to as the leader. At the same time, some interesting books were published on the development process. Notable books for me were Jim McCarthy's Dynamics of Software Development (Microsoft Press, 1995) and Steve McConnell's two books, Code Complete (Microsoft Press, 1993) and Rapid Development (Microsoft Press, 1996) They were inspiring; they made me realize I wasn't the only person struggling with these issues and that there were better ways to develop software. What's more, they were written by guys at Microsoft, one of the world's biggest software companies. Their strategies made even more sense to us because we were using the Visual C++ development tools, and Jim McCarthy's team wrote those tools. Well, if we could do as good a job as them, we would be okay.
That first start-up company didn't make it. We ran out of funding, and there was no real marketing effort. It was a shame we had written some excellent code that would never ship. The next step was to start up on our own. Six of us from the failed start-up banded together and decided to break out on our own. We had learned a lot of lessons, including that we needed to learn more.
Four years later, at that second start-up, someone discovered XP. It was 1999, and the dot.com buzz was in full effect. This company was delivering traditional C++ applications for the Windows desktop, using back-end databases and middle-tier COM business objects. The world had changed, and XP looked like it would help us keep up. I was intrigued, and never being far from the code, I tried some pair programming. It was fun. I bought a few copies of Kent Beck's book Extreme Programming Explained (Addison-Wesley, 1999) and handed them around. I worked with the team on task breakdowns. We built test frameworks and tried test-first programming. We had morning stand-up meetings to discuss progress and work out our strategy for the day. The interesting thing was that it didn't seem a very big jump from the rapid application development approaches that were introduced in the McCarthy and McConnell books.
We managed to complete a lot of work and have fun at the same time. The quality of our code also improved dramatically. The last project I worked on with this team shipped ahead of schedule and has never had any bug reports from customers. I believed I had to tell other people about what we were doing.
I had a stake in another company at that time. It was being engaged to develop some early-stage software using early versions of the .NET Framework. Much of the framework was pre beta and very flaky. I suggested they use an XP approach to help them learn the tools and protect themselves from incorrect assumptions. This worked well. I investigated further and found another company in London that was using XP. They were also doing very well. It seemed like a great way to develop software. That year I ran three courses on developing software using XP practices. The teams I worked with did a great job, and a year later I felt ready to retire. The 1990s were good to me.
A year and lot of adventures later, I found myself in Australia looking for companies that were using XP. I wanted to teach and code again. I was a believer, and I wanted to work with others who knew the "way" to develop software. Yes, I wanted to write code; it is what I do, I enjoy it. I love the creative aspect of software development. I love the purity of that creation. A Russian I once worked with used to say, "Hey, this is software; you can do anything if you have enough money." I believe he was right.
I formed the Sydney XP Activity Club (known as SyXPAC) and started teaching groups about the joys of XP. At the same time, Microsoft was getting ready to release the .NET Framework and the Visual Studio.NET development environment. I found myself working with the two together. I introduced them together in a course I started running called XP Techniques for .NET Developers. The result has been the creation of a number of eXtreme .NET development teams. Much of the material in this book comes from the lessons learned on those courses and the mentoring I have been doing with development teams.How to Read This Book
Most of the chapters in this book have exercises using the .NET Framework. Chapters 1 and 3 do not. These two chapters provide background knowledge for the rest of the book.
Chapter 1 provides an overview of XP. If you have read other books on XP and feel comfortable with the practices and values, you might be tempted to skip Chapter 1. Don't! Chapter 1 also contains an exploration of how .NET and XP work together.
Chapter 2 introduces pair programming. The exercises in this chapter require two developers. From this chapter onward, you can apply the pair-programming techniques to the exercises in the rest of this book.
Chapter 3 examines techniques for breaking down problems into small easy-to-achieve tasks. The exercises in Chapter 3 will help you understand the practices explored in other chapters.
Chapters 4 through to 7 cover the XP techniques that help you to achieve the goals mentioned at the beginning of this chapter.
Chapter 8 provides a deeper examination of techniques for writing code with fewer bugs.
Chapter 9 pulls all the techniques together into a single project. The Team
Throughout this book, you will encounter dialogue between members of a team. This team is learning to become an eXtreme .NET team. I have taken most of these conversations from real-world experiences I have had while working with software teams.
Note: I've edited out swearing for your reading enjoyment!
The members of the team are as follows:
eXtreme Eddie—Eddie has been programming for more than 20 years. He has done everything from mainframe work through to embedded systems. Eddie was an early adopter of XP techniques and has been using XP in Java projects for the past couple of years. Eddie embodies the XP spirit.
.NET Deepak—Deepak is a young, smart coder. He graduated last year but has been using the .NET Framework since it first went into beta. Deepak knows and loves .NET. Deepak represents all there is to love about .NET.
Skeptic Sue—Sue has been in software development for 10 years. She has been mainly developing Windows software in C and C++. Sue was promoted in her previous job to project manager, which she hated. She left and joined this team so that she could get back into developing software. Sue carries the scars from many failed projects and doesn't trust new ideas.
Panic Pete—Pete is very bright and comes up with amazing solutions for problems. He is the clown of the team. Pete has been writing code for 5 years but has never finished a single project he started. Pete panics when the going gets tough and verbalizes this panic. When this happens, he has previously quit.
Customer Chris—Chris is the internal customer for the team. He works with marketing and the customer support team. Chris once tried to write some code on a training course. He didn't enjoy it. Chris is a people person: He loves engaging in conversation.Conclusion
I believe that all developers can learn something from the XP practices and techniques. After reading this book, you may go on to embrace the full XP process, while other readers may feel they are not ready or that XP will not fit in their organization. Either way, XP has had a big impact on the way software is being developed, and everyone in the field of software development can learn from XP.
Software development is a career that requires constant education. XP provides a set of lessons that all software developers can benefit from learning.
I have used XP practices while writing this book. This book is Version 1.0 of what I hope to build on in the coming years. As with software, the content of future versions of the book will be dependent on the technology that becomes available. The future versions of this book will reflect the feedback from the users—that is, you. Therefore, please provide feedback, either directly to me via email or through the publisher, Addison-Wesley.
1 McCarthy, Jim. Dynamics of Software Development. Redmond, Washington: Microsoft Press, 1995.
© Copyright Pearson Education. All rights reserved.
Home
