Slashdot Mirror

James Edward Gray II writes "If you've ever wanted to know more about the agile programming methodologies, Integrating Agile Development in the Real World is a fine place to look for the answers to your questions. Various agile methodologies are explained, compared, and contrasted within. A good look is taken at how they work, their strengths and weaknesses, and how they compare to the more traditional approaches of software development. This proves to be a strong introduction and overview to agile programming practices." Read on for the rest of Gray's review. Integrating Agile Development in the Real World author Peter Schuh pages 346 publisher Charles River Media rating 8 reviewer James Edward Gray II ISBN 1584503645 summary An encyclopedia of agile software development practices.

The book opens with a couple of chapters exploring exactly what it means to be an agile development team. The author doesn't spoon feed you a definition. Instead, he takes a look at the Manifesto for Agile Software Development and pulls from that a collection of values important to agile software development. A list of agile principles is presented, and each of these aspects is examined from the angle of what it's trying to accomplish and where it can help when building software.

At this point, the book introduces seven methodologies including The Crystal Methodologies, eXtreme Programming, and Scrum. Each approach is defined by their practices and focus. The author does a nice job of telling you where these methodologies excel and even where they don't. The approaches are contrasted, but not with an eye towards finding out who is right and who is wrong. Instead, the author digs for the strengths in each practice.

The next few chapters offer suggestions about what agile practices can do for your development team, and outline how to adopt a few agile practices. This is one of the many places where the book really shines, thanks to its realistic approach. The author knows that not everyone can run out, soak up some eXtreme Programming training, and convert their entire division overnight. If you can, great, but this book is more focused on people who don't meet certain agile requirements and others who just want to test the waters a little. For these groups, there is sensible advice like, "Start by doing X, Y, and Z, because they're great ideas, easy to implement, and will help you a lot." If you like those changes, the author suggests what to try next. Even better, you're told to back away from the changes you don't like, sprinkle in some ideas from other methodologies, and even customize the practices to your needs. That may not be as extreme as some agile developers would prefer you to be, but it is agile programming distilled down to what it can do for you personally. I found that to be a great touch.

With the introduction to this new world of software development covered, the book moves into detailing actual agile practices. Early chapters in this section focus on the programmer, testing, and even the database side of the operation. Later chapters get into management, the project, and an agile development cycle. When a practice is defined, you're warned of prerequisites you should have in place before considering it, offered advice for how to get started with it, and even given a few variations that might work better for your group. I wouldn't say that the detail here is sufficient to teach you all you need to know, instead this section arms you with the knowledge to decide what you should be looking into. To kick-start your research efforts, a practice always ends with a list of further resources, available both online and in print.

The final chapters of the book get more abstract, dealing with customers, communication, and even just people. There's a lot of sound advice hidden away in these pages for some difficult challenges. I personally learned a lot about how agile development deals with customers and I have a few new ideas I'm anxious to try on my clients.

As an added bonus, the book has a very nice layout, filled with intelligent, witty prose and good looking charts. These effects are always subtle but can make a text a lot more approachable. I believe my only complaint was that the author tends to throw around acronyms assuming you know what they stand for. I think he even eventually got around to defining all but a couple, but not always when you first encounter them. A glossary probably could have helped in this case.

In summary, this book is agile programming for everyone. As a one-man operation, common practices like pair programming aren't even an option for me. The author knows that the methodologies aren't one-size-fits-all, and really focus on exactly what they can do for you, whatever your own needs may be. If you don't follow any development strategy (hope that's not true), would like to know more about the agile practices without joining a cult, or even just want to stay sane in your traditional software development company, Integrating Agile Development in the Real World will give you plenty of fresh ideas.

You can purchase Integrating Agile Development in the Real World from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

esnyder queries: "I find the pragmatic/agile/XP hype about test driven development compelling, but find it hard to see how to test first (or even unit test at all) in some situations. I would like to explore some extended examples of it in a moderate to large scale real world codebase to improve my test design skills. Can anyone recommend some F/OSS software projects that consistently use test driven development processes that I could check out? Preferable over 50K lines of code, but I'd welcome pointers to anything that people think would be helpful."

ivi asks: "I first bumped into the XP approach to system development, some years ago, on Dr Dobbs' now-defunct Seminar-On-Demand site TechNetCast. XP has some short, simple rules for growing software from Users' Stories, eg, with programmers working in pairs, showing prototypes to Users "early & often" et al. Download this XP site (under 400KB, zipped) for more. So, who's used or using XP, does it work for OSS projects & what have your experiences been with it, so far?"

ivi asks: "I first bumped into the XP approach to system development, some years ago, on Dr Dobbs' now-defunct Seminar-On-Demand site TechNetCast. XP has some short, simple rules for growing software from Users' Stories, eg, with programmers working in pairs, showing prototypes to Users "early & often" et al. Download this XP site (under 400KB, zipped) for more. So, who's used or using XP, does it work for OSS projects & what have your experiences been with it, so far?"

Shipud writes " Bio-IT World is running a story on how Gene Codes corporation created the Mass Fatality Identification System (M-FISys) in the aftermath of the 9/11 attacks. The story goes into the details of processing large amounts of data, aiming for a 99.9% accuracy rate, and extreme programing."

Webi writes ""XP[http://www.extremeprogramming.org/] works best for medium-sized teams where a product can be delivered in stages, and where there's freedom to experiment with some of the more controversial techniques," author Ron Jeffries said. http://www.newsfactor.com/perl/story/20348.html"

David Kennedy writes: "Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus by Hightower & Lesiecki is a welcome addition to my bookshelf at work. It tackles a gap in the Java book market in dealing with the thorny issues of testing, integration and deployment." The rest of his review is below. Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus author Richard Hightower & Nicholas Lesiecki pages 516 publisher Wiley Computer Publishing rating 8 reviewer David Kennedy ISBN 047120708X summary Practical introduction to Java tools for Extreme Programming, with an emphasis on immediate results rather than deep theory.

In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.

What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).

It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.

The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'

From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.

What's covered? Here are the chapter headings:

1. Introduction and Key Concepts
   1. Introduction to Extreme Programming
   2. J2EE Deployment Concepts
   3. Example applications
2. Mastering the Tools
   1. Continuous integration with Ant
   2. Building Java Applications with Ant
   3. Building J2EE applications with Ant
   4. Unit testing with JUnit
   5. Testing Container Services with Cactus
   6. Functional Testing with HttpUnit
   7. Measuring Application Performance with JMeter
   8. Load Testing with JUnitPerf
3. API and Tag Reference
   1. Ant Tag Reference
   2. Ant API Reference
   3. JUnit API Reference
   4. Cactus API Reference
   5. HttpUnit API Reference

If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.

Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.

You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

However skeptical the ads make you, it's hard to deny that what used to be considered supercomputing power keeps showing up in consumer-priced boxes, and the threshold of what really is extreme has crept steadily upward. If you're planning a project of more than average size, though, the review that chromatic contributed below of Planning Extreme Programming could be a valuable read, and the ideas in the book itself could save you a lot of money and time. Even if you have no plans to desire to install a beowulf in your broomcloset, it's interesting to consider what sort of thought must go into any large-scale programming project.

Planning Extreme Programming author Kent Beck & Martin Fowler pages 139 publisher Addison-Wesley rating 9 reviewer chromatic ISBN 0-210-71091-9 summary Guidelines, anecdotes, and tested techniques to plan and track your Extreme Programming projects.

The Scoop Last year's Extreme Programming Explained argued that all of the good activities of software engineering (planning, designing, testing, refactoring, estimating, reviewing, and releasing) ought to be done all the time. Dividing the technical and management tasks, forcing each group to work to its strengths, the technique has gathered several proponents. Until now, there's been no general presentation of the HOW of XP, suitable for management and customers.

Planning Extreme Programming covers the practice of XP, the techniques other groups have used while applying its principles. Data and anecdotes from XP practitioners contribute to this collection of lessons.

What's to Like? The book fits the XP philosophy handily, with short, simple chapters hitting a single point apiece. This is a book suitable for busy managers (weaned on slide presentations) and customers (who don't want to learn any more about programming than necessary). Without the support of both, projects will fail. An afternoon invested reading this thin tome will pay off handsomely, whether or not you use XP.

It's hard to pin down the main emphasis in the face of the gestalt. The strongest lesson relates a simple driving anecdote. Reaching your destination requires a successful combination of small steps and course corrections. You can't just point the car at Boston and accelerate. Back out of the garage first. Ready, fire, aim aim aim aim aim.

Instead, the authors suggest breaking a project into self-contained, testable components (stories). The customer creates the stories. The programmers estimate the time it will take to complete each. The customer selects the stories for the next iteration (period of time between release dates, generally three to six weeks). The programmers write their tests, write their code, ask the customer to postpone a story instead of slipping a release date. Finally, the customer runs the test and selects the stories for the next iteration.

It's a powerful concept, and just might work. The text examines each step of the process, with a consistently simple emphasis on the big picture. Of particular note are the sections on estimates (you can do as much work as you did in the last iteration) and the role of customers. The big benefit of XP is that it minimizes risk over the long term by producing working software as soon as possible, continually revising the overall plan with fresh data.

What's to Consider? This book really assumes readers already have some understanding of the part they play in Extreme Programming. (One might argue that there's no reason to read this book without having read Beck's first XP book.) The more open-minded in the audience may jump right in, while the cautious and practical will want proof to go with the manifesto. Invest in reading this and Extreme Programming Explained.

Related to the previous point, XP is not free of jargon itself. Readers unfamiliar with the role of 'stories' or the duties of the customer will have some difficulty with the first few chapters. A short glossary of terms and duties would alleviate this.

A criticism of Extreme Programming Explained also applies here -- there's still too little data about which projects and software types fit XP best. This book does present some criteria: projects running on Internet time, outsourced projects, and projects with medium-sized teams (six to twelve developers) are possible candidates. Only experience and more data can provide hard answers.

The Summary More practical and less controversial than its predecessor, Planning Extreme Programming makes the XP manifesto workable. Better for people already sold on the practice, the book is also appropriate for people considering Extreme Programming, whether programmer, manager, or customer. Improve software quality and your quality of life by embracing change. Table of Contents

1. Why Plan?
2. Fear
3. Driving Software
4. Balancing Power
5. Overviews
6. Too Much to Do
7. Four Variables
8. Yesterday's Weather
9. Scoping a Project
10. Release Planning
11. Writing Stories
12. Estimation
13. Ordering the Stories
14. Release Planning Events
15. The First Plan
16. Release Planning Variations
17. Iteration Planning
18. Iteration Planning Meeting
19. Tracking an Iteration
20. Stand-up Meetings
21. Visible Graphs
22. Dealing with Bugs
23. Changes to the Team
24. Tools
25. Business Contracts
26. Red Flags
27. Your Own Process

You can purchase this book at ThinkGeek.

That much software sucks -- perhaps most of it -- is hard to dispute. Except for the simplest programs, it seems like the price of complexity is a tendency to failure. Commands don't work, user interfaces are neglected to the point of ruin, and components of even the same piece of software often clash with each other. And once you start combining them and try to use more than one application at once, sometimes the best you can hope for is an operating system that neatly segregates the problems so that your word processor doesn't take down your web browser, your IDE or your e-mail client. At least those are desktop applications for individual users, though -- the trouble compounds briskly when the common faults of software manifest in multiuser environments, where one machine going down means a wasted time and frustration for a lot of people at once. In an effort to outline the ways that software could suck less is coding, reading and writing dervish chromatic.

Making Software Suck Less - Processes Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.

Distributed Development Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.

To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.

Test First The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.

When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.

Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.

Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.

Simple Solutions First After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.

"It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
-- Linus Torvalds

Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity. Have a Plan, Code For Your Users Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)

Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.

Continuous Design, Refactor With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.

"Premature optimization-including premature low-level design--is the root of all evil."
-- Michael Abrash

When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files. Release Often, Release Working Features Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.

Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.

Conclusion If we truly want excellent software, with well-developed features and no messy surprises, we need more discipline in our approach to creating software. In my experiences with these techniques (and in talking to other developers), I have found that even simply migrating to a test-first approach, though painful, has increased my productivity and my confidence. It's scary at times, but immensely satisfying. Taken together, who knows what levels of excellence we can reach?