Merlin42 writes: "I will soon be taking a class titled "Agile development methods," the required reading for the class is "The Art of Agile Development." I decided that I would read the book before the class and write a little review, and then do another review (or maybe a retrospective) after the class. The intended audience for this book seems to be anyone involved in software development who is interested in learning and applying agile methods. While it would definitely be useful for managers, testers, and customers; the main audience would definitely be developers.
Like many books these days it comes with its own web site that is slowly expanding to cover all the topics from the book. It is accessible at: http://jamesshore.com/Agile-Book/. I have not looked very far into this site, but it looks useful, and is currently up to about chapter 7 (out of 15).
This book assumes that the reader has had very little exposure to the details of "agile development." It provides a broad overview that would be useful and usable. Instead of going into extreme detail, it provides copious reference, many of which are freely available on the internet. This book provides enough detail that it could probably be used on its own to get started with agile development, but I would highly recommend further reading into particular techniques to get more depth before diving in head first.
In the introduction the authors state that most of this book presents a "little lie." This lie is actually a pedagogical technique that I found vey useful. Basically the majority of the book presents the techniques and practices that make up their own personal version of Extreme Programming. They make no attempt to catalog the dizzying variety of agile programming methods out there such as Lean, Crystal, Extreme, Scrum,... Instead they chose to go through one variant of Extreme that they have used and know can be successful. While they only present a single methodology, they do provide a good amount of detail on the underlying reasoning about why they do things their way, and details about how, when, and why you might want to do something a bit different.
The bulk of the book is made up of sections describing a particular technique or practice. These include such things as "Sit Together", "Test Driven Development", and "Incremental Design". Within each section it starts with a description of the technique that usually contains a few anecdotes about its implementation. These are often descriptions of failures that tried to avoid the technique. This is very helpful since I find that you can usually learn much more from failure than success. And who has the time to have a bunch of failures just to learn how to succeed?
The description is followed by several short sections titled: Questions, Results, Contraindications, Alternatives, and Further Reading. The Questions section is essentially a small FAQ listing the most common complaints/problems with the technique and the authors' viewpoints on them. These are usually spot on, and often matched word for word some concern I had about the technique presented. In Results they present the desired outcome and reasoning behind the technique being described. Contraindications lists situations that would preclude successful use of the technique. I often found this to be very enlightening. It was pretty thorough at listing what is truly required to get up and running with a particular technique. Alternatives lists useful ways to modify or replace a technique if it doesn't fit in with their work environment. Finally Further Reading is exactly what its name suggests. It provides places to go for more information.
I found the very structured layout of the book very helpful. This structure helps each technique to stand on its own, so that the book can be used well as a reference later. It also provided a sort of rhythm to the book that made it quite enjoyable to read in my opinion. Each technique was presented in a small digestible fashion. And all the references were close to the material they related to.
I found this book to be a very enjoyable read, and chock full of useful advice. I would highly recommend it as a starting point for anyone who is seriously considering starting an "agile" software project, especially if they are interested in XP. I would not consider this book sufficient on its own for starting out with agile development, but it does provide the basics, and a framework which can be filled in with experience and further reading. Also, the extensive references in the book would provide a great place to start when digging deeper."
Merlin42 writes: "I recently took a Test-Driven-Development (TDD) training course and the teacher recommended that I read "Working Effectively with Legacy Code" by Michael Feathers. First things first, a note about the title. Feathers defines "Legacy Code" a bit different than you may expect, especially if you are not into the XP/Agile/TDD world. I have heard (and used) a number of definition for "legacy code" over the years. Most of these definitions have to do with code that is old, inherited, difficult to maintain, or interfaces with other "legacy" hardware/software. Feathers' definition is "code without tests." For those not into TDD this may seem odd, but in the TDD world, tests are what make code easy to maintain. When good unit tests are in place, then code can be changed at will and the tests will tell automatically you if you broke anything.
Overall this is definitely an interesting read, and useful to anyone who has ever yelled "FSCKing LEGACY code!" It will be most useful to someone who already has some appreciation for TDD and wants to use it to "pay down the technical debt" in a legacy code project. In my opinion adding unit tests (a sort of retroactive TDD) is the best... err... most effective approach for getting a legacy code project into a more malleable state.
One caveat is that most of the book is focused on working with object oriented programming languages. There is some coverage of techniques for procedural languages (mainly C), but this is not the main focus of the book. In a way this is unfortunate, since there is a lot of really useful C code out there gathering dust. But in the book he states that "the number of things you can do to introduce unit tests in procedural languages is pretty small." Unfortunately I would have to agree with him on this point.
One of the greatest things about this book is that it is written by someone who has worked with a lot of legacy code, and there are numerous real world anecdotes sprinkled throughout the text that really serve to help drive the points home. The code examples are plentiful, but not verbose. They all look like real code you might find lurking in a dark corner at work, not some fanciful made up snippet.
The high level goal of the book is show you how to write good unit tests for code that wasn't designed with unit tests in mind. The first step for writing unit tests is getting individual classes or functions into a test harness where you can apply known inputs, and check the outputs or behavior. To do this you need to break dependencies in the original code. The bulk of the book is dedicated to looking at different approaches to breaking dependencies.
Much of the book is organized like a FAQ. There are chapter titles like: "I Need to Make a Change. What Methods Should I Test?" and "My Project Is Not Object Oriented. How Do I Make Safe Changes?". This organization makes the book work a bit better as reference than as learning material. After the first few chapters there is very little flow to the book. Each chapter tends to stand as an independent look into a particular problem common in legacy code. As a result, you can read the table of contents and usually skip to a self-contained chapter that will help with the problem at hand.
The final chapter of the book is a listing of all the refactoring techniques used throughout the rest of book. So if you have a particular dependency breaking,technique in mind you can skip straight to the description of the technique you want to use. This can be quite helpful when you need to perform a refactoring before you can get your code into a test harness. The descriptions are straightforward and provide a little checklist at the end that will help you make sure you didn't miss anything.
In conclusion I would definitely recommend this book to a colleague who is trying to introduce unit tests into code that was not designed with testing in mind. In fact I have already lent the book to several people at work, most of whom have bought their own copy."
Merlin42 writes: I recently bought a Olevia 232T. I just downloaded the updated firmware and noticed that it contained a "Linux Compressed ROM File System" which I was able to mount and explore. I was able to determine that the TV is running Linux 2.6.11 on a 32-bit MIPS processor. I suspect the TV contains at least 8 (and more likely 16MB) of flash. It also has a USB port, which is used to update the flash from a USB disk. This brings up several questions:
Has any one else mucked with this TV, or one like it? I would love to make a more sane menu system for the TV. Of Course mucking the menu would either require assistance from Olevia or some pretty serious RE work.
Could I get a USB NIC working on the TV?
And if so could I get mplayer or firefox working with it? The TV is definitely not running X so doing this would probably again require assistance from Olevia or some pretty serious RE work.