Customer Reviews

Practices of an Agile Developer: Working in the Real World (Pragmatic Bookshelf)

5 star:		(24)
4 star:		(3)
3 star:		(5)
2 star:		(2)
1 star:		(0)

 

 

In my own work, I am struggling with various agile vs. non-agile practices, but sometimes it can be hard to see why a non-agile practice is worse in the long run than an agile practice. This books goes a long ways toward identifying the problems with non-agile practices by identifying an agile practice, then showing the benefits of following it as well as the result if it isn't followed. Throughout the book, a little angel and a demon show up-the angel illustrating a "good" practice, and the demon illustrating a "bad" practice. This makes the book a fun read and I think really helps in illustrating the authors' points.

The book includes 45 different points that an agile developer should follow. For example, "Criticize Ideas, Not People" and "Keep it Releasable". Each section begins with one of these points, followed by a little demon telling you why you shouldn't follow the agile principle. More often than not, you'll find that the demon's arguments are things you might have heard from your co-workers, managers, or someone else in your work environment. After the authors' explain why the particular agile principle is important, the little angel sums up why the principle is important. Again, it sounds silly, but it's an effective teaching mechanism. It's also a lot of fun when the demon's arguments are ones you've heard before.

In reading the book, I had the sense that the authors were really trying to be unbiased in their discussion of agile. They present some very convincing case studies of how some projects when terribly wrong, and how it could have been prevented with some very simple agile practices. With some books on agile, you have the sense that the authors have never written a line of code in their life. This book was a good reality-check for me. The authors sound like they know what they're talking about, and they talk about real-life problems that all of us experience in our coding. I would highly recommend this book to developers looking to become more agile, but needing something that's actually applicable to the real world.

I bought this book because I had another Pragmatic Programmer book that I liked and wanted to see what best practices the Agile Developers had in mind. I was really disappointed in it. The short review is that, it's a decent book with a lot of good ideas, but the packaging up of those ideas left some to be desired, I'd recommend going back to the olde thyme Extreme Programming books and read the much more thorough understanding of how to work quickly and efficiently in this environment. This felt a little like cliff notes for Kent Beck's and Martin Fowler's excellent books. (and don't get me wrong, I'm not a crazy xp'er, I just read the books and took the parts that I liked and made sense to me)

The longer review...

The book is composed of tips. Most tips are about 2 to 4 pages, which make for a very quick read. This is both good and bad - it seems very overviewy. The structure of every tip, starts out with the title, a description of the tip and then a "what it feels like" little paragraph that gives you the emotional state you should be in when you are doing this and a "keeping your balance" bullet point. To me it feels very touchy feely/self-helpy and turned me off, but that's just a personal issue - others may find this format very novel and helpful. The length of each tip precludes it from going in depth into any particular one.

The first two chapters "Beginning Agility" and "Feeding Agility" read like some kind of self-help manual. To sum them up they mean to say,"Don't be a jerk to your team." It seems to me, anyone who is reading this book who is always assigning blame, looking for scapegoats, sticking fast to unsupportable claims - they are unlikely to change because the author's suggest that maybe that's not the best way. I'd wager that most readers of this book already are focused on working well with the team - at most this should have been a few pages. The second chapter spends nearly 20 pages that saying, you should keep your skills up to date and at least have a broad measure of what's going on in the ever progressive world of technology.

The next 4 chapters (the only ones before the epilogue), either repackage Extreme Programming (with unit testing, group ownership, iterative programming, quick feedback loops, keep the customer in the mix, refactor, keep things simple) with a couple more experiential suggestions. Strangely, they credit XP with stand up meetings, but none of the almost everything else they seem to have cribbed.

One thing they do throughout the book, that I like, is they suggest problems and solutions because of real world experiences they've had. I enjoy books that do that because you can see how people get to where they are and how they develop. Sometimes, their solutions agree with you or give you a new insight in how to deal with something.

The epilogue gives you some ideas on how to move to agile developing.


It's not a bad book. Generally the ideas are valid and work proven and will probably be useful to most people. Personally, I prefer the more in depth XP books from which this seems to repackage most of it's core ideas, it seems more like XP lite, that you can read in one sitting in an afternoon (which I did) and come away with a couple good ideas. So buy this for a quick read, but I'd say, if you're really interested in these ideas, go for the original XP books.

This is an absolutely terrific book. It's well-written and lays out 45 essential practices for starting and keeping an agile project rolling.

Each chapter starts out with a very sensible overview, pointing out where the practices for that chapter might fit. Each specific practice is nicely done, with short, to-the-point discussions of what the practice is, how you roll in to it, and how you stay in the groove with that practice.

There's a lot of goodness in the bibliography for additional reading, plus the epilogue, "Moving To Agility" is worth pasting on the foreheads of stubborn mangement who are unwilling to listen to rationale for improving the development environment. The specific steps for rescuing a failing project are terrific, as are the other epilogue sections.

Lastly, there's a nice pull-out reference card with one or two sentance blurbs on each practice.

Sheer gold.

This book by Venkat Subramanian and Andy Hunt (one of the authors of "Pragmatic Programmer") provides an interesting view into the life of an agile software developer. So many of the misconceptions of what agile development processes are (and aren't) are broken by this book with its clear articulation of the foundational tenets of the concept. Having worked with TJ Hadfield, one of the key fathers of agile development at the C3 project, I can say this book re-enforces much of what I've learned from him and his many years of wisdom and experience.

Too many folks have derided agile software development as a `do whatever you want' process that isn't a process. This book does a good job at clearly stating the goals of an agile developer and walking through what the process means to the developer. It paints the true picture of the process and the foundation: treating developers and responsible professionals capable of implementing a solution without enough information. Agile admits that we'll always be imperfect in defining the specification, so it embraces the concept.

Other key points the book covers includes: Daily stand-up meetings. Finding bugs early. Test driven development. Nightly builds. All with the goal of making a schedule by making lots of little milestones. Plus, putting a process in place that hums along with a rhythm. A nice call-out in the book identifies out practical tools required for the agile developer including the wiki (for documentation), continuous integration, automated build and others.

The playful tone of the `devil' and `angels' on the shoulders of the developer is an interesting way to present the problems in software and solutions presented by agile, even if it's a little condescending (as though we're all intent on listening to the worst advice in software development). I understand the intent but could imagine a little less cartoon-ish way of presenting the problem/solution mix.

Overall, an excellent book to walk through what it's like to develop in an agile process and how it will feel once it's done. It provides insight into how to adopt it successfully and gives perspective on the end-product you may not see immediately.

Practices is pretty well just that - a list of practices for agile programmers. If you haven't done agile before or are just getting started, then this will provide you a good primer for getting a handle on the most important practices that span most of the agile methodologies - XP, Scrum, Crystal, etc. It is very readable and is organized in a way that you can use it for reference later to look up specifics about each practice.

What makes the book only average however is the general way that it defends each practice. In contast to another Pragmatic Programmer title, "Ship It!", there is a lack of explaination of the "why" of each practice. In some cases, they take a shot at explaining why, but it general terms that aren't really compelling. (They certainly won't be compelling if management or your peers are skeptical of agile practices.)

Even if you believe in agile, as I do, you need to understand why you do certain things and how each of those practices fit together to support each other. Software development isn't about blindly following a process - you have to understand what you are doing. For that, you'll have to look elsewhere.

The authors open the first chapter with a Turkish proverb - "No matter how far down the wrong road you've gone, turn back." Good advice for life in general. Turns out it applies really well to dorked-up software development projects.

If you are new to agile software development practices, this book is a great, high-level introduction. Most of what software developers consider 'agile' practices are merely common sense - common sense acquired by programmers after much time spent doing things the hard way. Other programmers will keep doing things the hard way, because they simply have never seen, learned or figured out a better way to do it. Like most geeks, they occasionally need an introduction.

If you already use agile practices, you'll find this book a warm affirmation of what you're already doing. You might even find something in here that will help you squeeze out a bit more productivity on your projects.

The book addresses two of the more curious problems that keep teams from working with agile practices - where to start and how to keep it going once you do start.

The first chapter describes agile software development in general terms to help you get acquainted. Each additional chapter digs a little deeper by covering several practices related to the chapter title. Each practice is explained clearly in a few pages and is followed up with "What It Feels Like" and "Keeping Your Balance" sections that give a very succinct review of the practice.

The book is easy to read and short enough to keep as a desk reference for quick look-ups. A "Resources" section at the back of the book is a great jumping off point with links to excellent articles, tools and resources. The "Bibliography" section lists many useful books to help you explore the subject further.

But wait, there's more! A perforated, four-page cardboard foldout at the end of the book summarizes each of the forty-five practices.

A book like this in the hands of a ready-to-learn programmer might produce a wonderful growth spurt in the programmer's productivity and code quality. In the hands of a ready-to-listen software manager it might ultimately influence an entire team of developers in a positive direction. All in all, it's a well written book that I highly recommend.

by Dave Walz-Burkett

I received "Practices of an Agile Developer" just yesterday in the mail and was compelled to read it practically non-stop & it is definitely worth the time spent reading. I even took it with me out later that evening as I met up w/ a friend of mine at the bar, and over a beer we thumbed through the book.

Lately, I have been hearing a bit distant in the background noise din about agile programming, as a methodology and this was the first book I've read about it, so it all is an introduction to me. Over the years and the handful of work experiences I have had, I have come to realize that its not really the program that needs to be debugged, but its the programmer, or its the team. If you can get these issues involving the people solved, everything else will come right through. Its about debugging the mind, debugging the workplace. Kinda like "free you mind, and your A#$ will follow." And I think that this book goes a long way in expressing that, as well as finally giving us some tools to cope. Its based in real, every day programming experiences, as in reality, as opposed to a more abstract, more perfect world-like situation.

Honestly, I wish that I had this book and am still thinking to give a copy of the book to the last place that I worked. So many of the first few sets of principles, right out of the starting gate, such as "Work for Outcome" and "Quick Fixes Become Quicksand", and "Criticize Ideas, Not People" were almost as if they'd been written by someone who had spent some time with the team that I was on. Later chapters on techniques such as the "Tell, Don't Ask" principle and "Substitute by Contract" have made me realize that there are so many things that I can be doing better. Its also piqued me to seek out information on the work of Barbara Liskov.

Finally, there are a handful of quotes from Ron Jefferies, and at first I thought that they were from Ross Jefferies, of "Speed Seduction" fame, and excitedly thought that the authors were trying to increase my programming skills by using similiar tactics as Ross does with helping us all out with "the Game." I think, in a certain way, it does just that!

I've actually been anxiously awaiting this book ever since I saw Venkat speak about Java generics at conference last year - and I wasn't disappointed! Whether you're already doing agile development or just looking for a good resource to get started, this book is a must read.

PaD covers what you would expect from a book about agile development including integrate early and often, automate deployment, use short iterations, collective ownership, and keeping it simple. However, it's the personal practices that set this book apart from others on the subject. Practices of an Agile Developer discusses many of the "soft" aspects of software such as criticize ideas instead of people, keeping up with change, and the importance of rhythm.

Speaking of rhythm, this book is a joy to read. Unlike some tomes that drone on and on, PaD presents material in easy to digest chunks of 2-5 pages making it particularly approachable for those of us with limited contiguous reading time! Venkat and Andy do a great job of putting these practices into context by providing "devil" and "angel" quotes throughout (and if you're anything like me, some of those devils hit awfully close to home...). Each section leads off with the devil tempting you to do something foolish and ends with an angel's advice on following the practice.

It's one thing to read about something but unless you've actually successfully applied the knowledge (or have Venkat and Andy on retainer), it can be very difficult to know if you're doing it right. To help reinforce the material, each section gives you a sense of what the practice should feel like and as someone that has only worked in pseudo agile environments, I found these pointers particularly helpful!

Subtitles are often overlooked - but "Working in the Real World" really is fitting. Unlike some books that preach practices that only work in narrow niches or the halls of academia, this book gives you practical advice that you can apply to your work today.

"Agility" remains a popular buzzword in the industry. Methodologies, tools, and even programming languages have had the adjective applied to them. But what does it mean to be an "agile developer"? How do we know if we're "agile"? Should I expect the ladies to saunter over at parties and say, "I couldn't help noticing that you're agile, how about coming back to my place"? To answer these questions, a good place to start would be to read "Practices of an Agile Developer".

This book, which could have easily been titled "Forty-five Habits of Highly Agile People", starts out by defining agility and what it means for something to be agile. It then proceeds to layout forty-five agile practices grouped into seven areas: Beginning Agility, Feeding Agility, Delivering What Users Want, Agile Feedback, Agile Coding, Agile Debugging, and Agile Collaboration. Your companions on your journey are a demon whose taunts remind you of how not to do things, and a guardian angel eager to steer you onto the path of righteous agility. Each practice is well motivated and adequately described. Additionally, each has sections letting you know what it should feel like if you are following the practice correctly, and how to strike a balance to keep from going overboard or not far enough when following a particular practice.

While the focus of this book is agility, the practices described really lend themselves well to all developers, even the agility impaired. Practices such as "Question until you understand" and "Write cohesive code", to name only a couple, are just plain old good advice for anyone who writes code. So even if you don't aspire to reach the summits of agility, you can look at this book as a self-help book for developers. Read it, soak in some of the good sense it offers, and be better for it.

This book is written in a very clear, straightforward, and enjoyable way. Every topic is well justified and supported by real life examples and metaphors. This approach makes them look like simply common sense practices, but in fact rarely followed in your day to day duties. Even already known guidelines are worth to review them.

Through these practices, any person involved in software development may understand a little bit more of how this business works, how all interactions and collaborations are equally important to achieve the project goals. The authors not only covered inherent developer related aspects like design, coding and debugging, but also general effective team work habits like: "criticize ideas, not people", "invest in your team", "be a mentor", "allow people to figure it out", etc. On the other hand, as an agile book, they also provide a good deal of advice about how to effectively collaborate with users and customers, including topics like: "let customers make decisions", "listen to users", "get frequent feedback using demos", etc.

Every practice is presented in the following standard way, making them easy to approach and understand:

* Introduction: identified by a little evil's icon, starts the topic by confronting you with bad habits and shortcuts that many of us are familiar with, in one or another way. Sometimes, this section makes you think "I've done/seen this, is doesn't look that bad". But actually, when you go to the main section, you easily realize the negative aspects of them.

* Main section: the authors explain in plain English, why those evil's habits are none recommended, referencing real life situations and metaphors. At the same time, they will show you the right way of dealing with specific situations and scenarios.

* Do what's right: identified by a little angel icon, points out in a clear and brief expression, what should be the right thing to do in regards with the topic.

* What it feels like: this section gives you a subjective hint about how practicing the right thing should feel like.

* Keeping your balance: provides additional sanity check hints, that will allow you to avoid abusing of any given practice.

I would definitely recommend this book to agilists and non agilists, developers, project leads, architects, managers and customers that are really engaged in their projects. It will provide in every case, valuable pieces of advice and reference points that will allow you to have a different perspective of this team-work-business of software development.