Chris McMahon's Blog

Very recently I was part of a bug hunt: an effort to find as many defects as possible in a UI in a short period of time. I am not an outstanding UI tester. I have worked with testers whose eye for detail, line, color, consistency, work flow, etc. etc. make them really outstanding testers to have examining the front end. But I've spent most of my career on green-screen apps, test automation, environment maintenance, stuff like that. I lack the really expert artist's eye that great UI testers have. That said, I was on a roll on this particular bug hunt, finding a lot of nice, sophisticated bugs. It was classic ET: decide a test approach, determine your next test based on the results of your last test; and when you stop finding bugs, change your test approach. I'd followed all the logical paths I could think of; I'd tried really big inputs and really small inputs; I'd tried permissions errors, navigation errors, and checking error messages themselves. I tried ...

My colleague Matt Heusser is doing this workshop on technical debt soon. I posted a little meditation on techdebt as impedance mismatch , but that seems to me to be trivially true, facile. Since I made The Software Artists public, though, I've been fielding a lot of questions on the software-test mail list that has me rethinking my position on technical debt. So here is what I *really* think: Technical debt doesn't really exist. At least, it doesn't exist for high-performing software teams. It's a useful concept for those encumbered by poor programming and poor testing, but the idea ceases to be useful about the time the code base becomes manageable. I have a graph and and I have a metaphor that both explain my position. I'll just describe the graph because I'm too lazy to hunt down some free software to draw it. This graph describes a couple of different projects I've been involved in, for a couple of different employers. The critical line on the gra...

Citations For the section “Practicing, Rehearsing, and Performing Software” Programmer, poet and guitarist Richard Gabriel's quote is from his proposal for a Master of Fine Arts in Software: http://www.dreamsongs.com/MFASoftware.html Apple CEO Steve Jobs' quote is widely noted, but is documented in context by Andy Hertzfeld here: http://www.folklore.org/StoryView.py?story=Pirate_Flag.txt The practice/rehearse/perform rubric was first presented on the author's blog in September 2007: http://chrismcmahonsblog.blogspot.com/2007/09/become-better-software-artist.html The title of this paper comes from the author's blog post of May 2007 in response to Jonathan Kohl's recommendation of theater and musical experience for software testing: http://chrismcmahonsblog.blogspot.com/2007/05/here-come-software-artists.html A performance by Ella Fitzgerald and Count Basie available on YouTube was a strong influence on this paper, cited in response to another of B...

Software development is a performance exhibiting skills developed by an individual—often in groups of teams... -Richard P. Gabriel Real artists ship. -Steve Jobs Since the language of art criticism provides useful tools for evaluating software, and the practice of teaching music provides useful approaches to teaching software, it is reasonable to think that the practice of artistic performance should provide useful ways to approach creating software. Only one way to build software has ever been acknowledged: software is designed, coded, and tested. Sometimes the design/code/test cycle is done a single time, sometimes design/code/test is done iteratively or incrementally, sometimes, as in Test Driven Development, the steps are moved around, so that the cycle goes test/design/code. But this is not how human beings create a performance. Instead of design/code/test, artists have a cycle of practice/rehearse/perform. Since human beings have been creating performances since p...

Citations for the section “Pedagogy and Practice in Software and in Guitar” Some of Joel Spolsky's writing about working with young software creators is at these links: http://www.joelonsoftware.com/articles/CollegeAdvice.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/items/2008/01/08.html Thoughtworks University had been called “Thoughtworks Boot Camp” until the author had to explain the term upon crossing an international border in 2005. A description of Thoughtworks University is here: http://www.thoughtworks.com/work-for-us/TWU.html Some representative citations from IEEE publications about poor software education are: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/8994/28540/01276501.pdf http://stevemcconnell.com/ieeesoftware/eic12.htm http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/so/&toc=comp/mags/so/2002/05/s5toc.xml&DOI=10.1109/MS.2002.1032848 The citation from CrossTalk is here: ...

Very few people graduating with a college degree in Computer Science or Information Technology are prepared to write production code or to test production software. Companies that hire recent college graduates often have special training for such employees before they may work on actual projects. Joel Spolsky has written extensively about how his company Fog Creek trains young software workers. Publications of the IEEE mention the issue frequently. The well-regarded software consultancy Thoughtworks has “Thoughtworks University”, a six-week “boot camp” style training event for new hires hosted in Bangalore. Even the journal CrossTalk: The Journal of Defense Software Engineering says: It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. The Craft of Software Besides the mentorship approach Spolsky takes and the “boot camp” approach Thoughtworks takes, Robert C. (Uncle Bob) Martin, Pete McBr...

Explanation Introduction The Value of Software Citations for Part One Pedagogy and Practice in Software and in Guitar Citations for Part Two Practicing, Rehearsing, and Performing Software Citations for Part Three