Thunderclap, the Newsletter of Rolling
Thunder Computing
Volume 11, Number 1, Fall of 2009
In this issue:
Blatant Self Promotion: David Platt's Training Classes
Programming Microsoft Health Vault, Online Dec 16-18 2009
Prism, the Composite Application Library and Composite Application Guidance, ONLINE Oct 27-29, 2009
Microsoft Insurance Value Chain for ACORD, ONLINE Dec 4, 2009
Feature Article: A New Way to Learn Software, Inspired by Norm Abram
Book from David Platt: Why Software Sucks (and What You can Do About It)
Inspired by Norm Abram
Developer training was the first thing companies slashed when the economy tanked last year. With money so much tighter, many of my customers didn’t feel that training provided the value that they now needed. Instead of sending developers to a public class, or scheduling an in-house class to ramp up a whole team, companies were more inclined to throw them a book and say, “Here, read this, figure it out, and start doing it. And hurry up.” The developers, happy to keep their jobs, would do their best, usually burning a lot of their own time in the process.
At the same time, my developer contacts were reporting that this self-instruction approach was not working out well. Superficially it seemed cost-effective. But invariably they’d get a couple of months into a project and find that, while their initial approach had seemed logical at the time based on what they then kne, they’d gone up a blind alley, they were stuck, they had to backtrack and rearchitect their applications. In the long run, it cost much more. The alternative wasn't working. But clearly, developer training needed a change to fit into the current economic climate.
So I asked myself the question that I ask the audience when I give my Why Software Sucks keynote talk: what are my customers really buying from me? Developers think their customers are buying software, but they’re really not. They’re buying the results of what the software does – a tracked package, a balanced bank account, a correctly treated patient. Software sucks because developers don’t realize this. Here you can see a video clip of my keynote talk at SD West on that specific issue. (Or the other, more famous one here: Software sucks because geeks drive stick-shift cars). Do my customers buy training because training is that they want? Of course not. What do they really want when they write me a check?
Short answer: “Better code, faster.” As simple as that, or as complicated. They want a good quality application out the door and earning money for them as quickly as possible. How do I help them get more of that?
As master carpenter Norm Abram wrote in his book about building his own house: “A rule I adhere to firmly is this: If you start square and level, the rest of the house goes together smoothly.” More than anything else, that’s what developers and their companies need from a training class. They need to start their projects correctly – design them from day one in a way that uses the best practices for the new things they're learning, which often aren't apparent in the beginning. Design them in a way that doesn’t go up blind alleys, that won’t have them throwing it out and redesigning it in three months or six. They need to adhere to the software equivalent of Norm’s rule. So that’s how I’m structuring my classes today. I don't just teach you stuff, I help you apply it to your product design to get your project started square and level.
Here’s how I figured it out – by accident, as all great discoveries are. I was teaching ASP.NET at a client here in the Boston area. This client was switching over from Java and needed to learn the .NET way of doing things. As I always do, I customized the curriculum to take into account what the client’s developers already knew and what they still needed to in order to reach their specific goals. In this case, the client needed to make ASP.NET Forms authentication work with their existing non-Microsoft single-signon system, and they also needed to interact with a particular legacy database in a particular way. So I adjusted the lecture topics to spend extra time on these specific topics.
But the real breakthrough was that, instead of working on pre-packaged labs, we spent our lab time working on these particular problems that the client needed solved. We actually did a small agile development project, right there in class, starting on Monday. We wrote down the priority projects, picked the top two, stripped them down to their technical essence. We assigned a feature to each top developer and assigned another developer as understudy. I went from group to group, guiding their efforts, clearing snags, explaining the new things they were encountering, suggesting future lines of investigation based on what they were learning and doing.
The results were fabulous. The client said, “Wow, it’s amazing to get that one [single sign-on] solved. You saved us five times the cost of this class from just that one thing, and it’s only Wednesday.” And I’ve been teaching classes that way ever since. Instead of pre-packaged labs, we start working on your specific development projects on day 1. When I give the lecture about, for example, modularity in Prism or CAB, we spend our lab time working out the modules that the program should be divided into, figuring which classes of user are going to load which set of modules and under what circumstances. When I talk about services, we discuss the client's packages of logic that should be factored into services, where they should live, how they should be injected and so on. When I taught about HealthVault, for another example, we discussed the ways in which the client thought they’d get their patients connected to the system, and worked out a much better approach.
So I don’t just teach a technology any more. I actually take your development team and get them started on their project, square and level as Norm says. And if you like, we can schedule regular follow-ups, weekly or biweekly, to ensure that you’re staying square and level. I help you get better code out the door faster.
Because of the economy, I had to stop and rethink just exactly what my value proposition was. And when I did that, I found a really good way of improving it. That’s what capitalism makes you do. Now my clients are getting a whole lot more out of my classes, and without this crunch it probably wouldn’t have happened. Go figure.
Until next time, as Red Green would say, "Keep your stick on the ice."
Why Software Sucks (and What You Can Do About It)
ISBN 0-321-46675-6
Sample Chapter Online at www.whysoftwaresucks.com
It's finally out! Anyone whose spoken with me in the last couple of years probably got an earful about the latest bee in my bonnet, the book entitled Why Software Sucks. I’m sure that I’ve inflicted sample chapters on just about everyone I know.
It's gotten a storm of publicity, primarily from a Reuters wire service article that ran during the first week of the new year. It was picked up in the electronic editions of such publications as the such as the New York Times (http://www.nytimes.com/reuters/technology/tech-software-platt.html) , Fox News, (http://www.foxnews.com/story/0,2933,241578,00.html), and PC Magazine (http://www.pcmag.com/article2/0,1759,2078820,00.asp).
I've started a new blog based on it, at www.suckbusters.com . It's dedicated to the notion that software shouldn't suck. Instead, software should Just Work.
The title was originally my idea, but I also love the subtitle, suggested by my editor at A-W. I’ve always thought that the right subtitle can really make a book. Like the 60’s bestseller Everything You Always Wanted to Know About Sex (But Were Afraid to Ask). Or Werner von Braun’s autobiography, entitled I Aim for the Stars. Humorist Mort Sahl suggested that its subtitle ought to be, But Sometimes I Hit London. (If you don’t get that last one, go look up von Braun online. As Tom Lehrer famously sang about him in the sixties: “ … A man whose allegiance is ruled by expedience … ‘Once the rockets are up, who cares where they come down? That’s not my department,’ says Werner von Braun.”)
This is my first book aimed at end users, not programmers. Early returns from this market are highly positive. My barber, the librarian at my local public (dead tree edition) library, and the contractor who built my house, all report that early chapters are informative, entertaining, and easy to read.
I’m still working on the “what you can do about it,” piece. If you have any thought as to how ordinary users can make their voices heard, I’d like to hear them. Use the contact info link of this web site, if you don’t already have my email. Thanx.
And now, the moment for which I know you've all been waiting -- the pictures of my two girls. Lucy is 6 years old in first grade, looking forward to 7 just after the turn of the year. Annabelle is now 9 and in third grade. Here the two girls are with Annabelle's 9 year old birthday cake.
Here Annabelle relaxes in our pillow corner with a book and our cat Starlight, who comes from Up River Ragdolls. She's started violin lessons at school and sounds astonishingly good for only three weeks in. Maybe I'll put a recording in one of these newsletters soon.
Lucy loves her gymnastics. She tried out for and made the Mini Team, the gymnastics team for her age group at the local YMCA. I built her a low bar on our play set, and she spends a lot of time practicing. Is she the next Olga Korbut? More to the point, can she get a college scholarship for gymnastics? She loves it so much, she doesn't even realize how hard she's working. That's something, ain't it?
Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe, jump to the Rolling Thunder Web site and fill in the subscription form.
Legal Notices
Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.
Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.
This newsletter is Copyright © 2009 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.
Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.