In homage to The Legend of Ninja, Cowboy, Bear, Adam Goucher has written a fairy tale about three kinds of software testers: zealots, anarchists, and robots. Cute, but also thought-provoking.
Not unexpected, but still disappointing:
TO: Prof. GV Wilson
RE: NSERC 2009 Competition Results
Title: Software process improvement in scientific computing
Program: Discovery-Individual
NSERC has released the results of the 2009 Grants Competition to University Research Offices. I regret to inform you that your application was unsuccessful.
Put the date in your calendars — more details to come.
…and here they are: http://democamp.com/2009/04/21/democamp-toronto-20/. Once again, the first batch of tickets has sold out almost immediately…
This time two years ago, most of them would have been computing books; now, they’re a minority. Still looking for a readable, grounded, fast-paced guide to instructional design…
A conversation with an ex-student yesterday reminded me of a post I’ve been meaning to write for at least a few months. He’s now a user experience designer, and believes that with a new generation of natural interfaces hitting the market (voice, tabletop, etc.), software developers will have to involve designers early and often, or suffer massive failure.
My counter is that people who care about UXD said the same things when GUIs first hit the mass market in the 1980s and when the web exploded in the 1990s Both times, though, the bulk of the software industry carried on treating design as an afterthought or luxury, in part because of intertia, and in part because companies that didn’t spend money on design seemed to do just as well in the market as those that did. (Remember the first few years of eBay and Hotmail? Brr…) If you’re going to claim that “this time will be different!”, you’d better have more than a wish-it-were-so argument to back it up.
My ex-student accepts that software developers have been able to slack on design because of the different costs of physical and virtual change. If you want to change the shape of the arms on a pair of sunglasses you have to cast new dies and tweak the assembly line, both of which cost tens of thousands of dollars (at least). If you want to change the layout of a few menus, on the other hand, you can just rewrite a few lines of code, recompile, deploy the new JAR files, and hey presto, you’re done. Yes, the real long-term cost of changes to software is much greater than that, but the difference in malleability is still so great as to be a difference of kind rather than degree.
I think we’re about to see a fundamental shift in the malleability of physical things, and that as a result, we’re about to see the software design tail start to wag the physical manufacturing dog. 3D printing and mass customization are at the same point now that desktop printing was in 1985: hardware was temperamental, and still out of reach of casual home users, but had suddenly reached the point where you could get a laser printer and a Mac for about what your cousin was spending to buy a delivery van for her flower shop. I was there—in the summer of 1985, I was programming a first-generation Mac with a three-digit serial number, and showing my brother (an industrial design student at Carleton) how MacWrite and MacPaint could rock his world. I believe this is about to happen to a hundred different kinds of manufacturing: plastic children’s toys, cutlery, sunglasses, door handles, and just about everything else made of plastic or aluminum alloy that’s the size of your fist or smaller.
What I think will happen then is a reversal of what designers working in the software industry have been calling for since the 1970s. Instead of software design becoming more like “real” engineering, we’re about to see the latter become more like the former. If sunglasses are printed on demand in the store, and changing the design is as simple as uploading a new spec from the web into the printer, then people designing sunglasses will be under exactly the same pressure to “fix it today” that software designers have been dealing with since the advent of timesharing terminals. Five years from now, I predict that software designers who’ve been griping about never being given enough time or enough respect will be on the lecture circuit teaching their ID and IE counterparts how to be agile, live with chaos, and cope with design cycles measured in hours rather than months.
Long story short, I think that anyone who’s trying to get software firms to act as if they were designing for a 1950s-era assembly line is betting against history. I think that if you want to reshape design today, you should put your money on the barbarians on horseback with their funny-looking stirrups and their recurved bows, not at the orderly legions drilling in their tidy little camps. Whichever way it goes, there’ll be a lot of noise and confusion—but that’s just another way to say, a lot of opportunities for people who are willing to turn things upside down.
SEED (the Software Engineering Evidence Database), is at http://www.evidencebasedse.com. I found it via Janzen and Ryoo’s paper “Engaging the net generation with evidence-based software engineering through a community-driven web database”, Journal of Systems and Software, 82 (2009), pp. 563-70, DOI:10.1016/j.jss.2008.12.047. The site contains paragraph-sized summaries of over 200 empirical software engineering studies, indexed by them. There’s no rating/ranking system, but lots of useful detail—a typical entry is included below to give you a flavor. According to the paper, contributions are actively sought…
This thesis introduced TDD, SCRUM, and pair programming to a developer team in PetroSleuth. One main threat to the external validity of the study was that the team was relatively small with many developers that just joined the team from just coming out from a university. They found that implementing a TDD practice had its difficulties. One was that the build would break due to the complexity of the build rather than the source code, another was that some developers had trouble translating tasks into tests, and they had difficulties learning how to write tests and use the test framework. At the beginning developers were not using TDD, and pair programming as much but towards the end of the case study, they were using these practices much more often. The case study is considered a success even though more needs to be done in order to refine the study and gather more accurate data.
C. Mann, An Exploratory Longitudinal Case Study of Agile Methods in a Small Software Company, master’s thesis, Dept. Computer Science, Univ. of Calgary, 2004.
Type of Study: Case Study
Methodology: TDD
Duration: 8 months
Company: PetroSleuth
Type of project: Windows-based oil and gas project management with
statistical modeling elements
# of developers: 4-7
project life: legacy
Team Language Experience: Experienced
Language: C#
Collocation: Collocated
The students in the combined CSC494/CSC2125 consulting course showed off their stuff at the Graduate Student Union yesterday, and I think it went well (see here for the original announcement and project list). 19 graduate and 21 undergraduate students had posters and demos for 20 different projects; by my count, about two dozen people showed up from industry, and another thirty or so from the university (though sadly only two CS profs put in an appearance—perhaps we would have seen more if I’d advertised the free beer a little more aggressively). All the feedback I’ve had so far has been very positive, and several students are intending to carry on with their projects after the term is over.
My thanks once again to everyone who took part—I promise to post pictures just as soon as I get them.
Update: Microsoft’s Joey deVilla has posted his impressions, with pictures. Thanks, Joey.
Another update: Andrew Louis has posted the photos he took—I’ll have to remember not to stand on chairs in the future. Thanks, Andrew 
And Misa Sakamoto has posted her impressions as well.
The second Toronto SciBarCamp will run May 8-9 at Hart House at the University of Toronto’s downtown campus. See the home page for details.
Leaders panel discussion – Toronto, Canada
Open source has been accused of being anti-capitalist, the saviour of government, and a way of breaking vendor lock-in and saving money in a down economy. This panel discussion involving senior leaders from open source organizations will explore these themes and provide valuable insights.
PLEASE NOTE: even if you cannot attend due to schedule conflict or geography, you can participate by submitting and voting on questions to be used by our moderator.
Panellists:
A final panellist will be announced shortly. The panel will be chaired by Andrew Ross.
Schedule:
This event takes place on April 23, 2009 in Room 1101 of the Sanford Fleming Building at the University of Toronto.
19:00-19:30 – Networking, food & drinks provided
19:30-20:15 – Leaders panel
20:15-21:00 – Q&A session
Recent Comments