For as long as I can remember, I've been interested in why things are the way that they are. Over time, that intense curiosity has driven me to learn as much as I can about object orientation and software development in general. I like to find out what works, and what doesn't and tell people about the boundary conditions. Working with Groupon, I'm able to really dig into various areas of software, solve problems with people and communicate what I've learned.
Knapsack books:
I'm currently using the IoLanguage and thinking about better ways of teaching design.
I can be reached at mailto:michael.feathers@gmail.com Blog at http://michaelfeathers.typepad.com
On SingletonsAreEvil you said you were writing a paper about that topic; I see people asking how that was going, but no response. Did this paper die before seeing the light of day? -- DougMerritt
No, I never finished that, but I've just finished writing a book on working with legacy code. Nearly all of my arguments against singletons are in there in one form or another.
Irony: In the olden days, we just had Goto-oriented SpaghettiCode. These days, we must deal with DesignPatterns-influenced SpaghettiCode. --PhlIp
Don't be shy, go ahead and tell us about it, ISBN and all. :-) -- dm
Okay, here is a brief description: It can be very hard to make changes in large complicated code bases. When we make changes its important to know that we are making them one at a time. Too often we think we are changing only one thing but instead we end up changing other things unintentionally: we end up introducing bugs. If we can write tests against old code we can figure out when it's behavior is changing. This helps us know that we've added new code properly and it also supports us when we refactor. Unfortunately, it's often hard to get tests in place in complicated code. You have to refactor to get tests in place in order to refactor. The book shows you now to safely get tests in place to support your work and start to make the code better.
When you do this often enough you start to see code that doesn't have tests as legacy code. The differences between code bases that have tests and those that don't are so significant in most cases that they swamp most other criteria for good design. When you have tests you can make things better, when you don't often you don't really know whether you are or not.
"WorkingEffectivelyWithLegacyCode" ISBN 0131177052 released September 16, 2004
I would think that a title like that would appeal to a lot of people without even knowing the contents. Don't forget to have some friends seed the Amazon reviews; the system is biased against authors who don't do that. (When I do this for friends, I do full disclosure on the existence of a personal relationship, but doing so is very much in the minority.) -- dm
WEWLC is a fantastic book. Right up there with Refactoring and Agile Software Development. Thanks for writing it. - BillDehora.
MichaelFeathers was the original author of CppUnit and CppUnitLite
Recently, I've written a tool that creates FeatureDiagrams for Java classes. I have a few pictures here that show what WardCunningham's FrameworkForIntegratedTest looks like in FeatureDiagrams: http://michaelfeathers.typepad.com/michael_feathers_blog/2007/02/feature_diagram.html