This week I managed to squeeze in three days of consulting and two days of public teaching. Side effect: less time over for reading. Still, here’s some of the stuff that piqued my interest online this week.
Bright and Terrible
Jay Yarow of Business Insider published a short post about what’s it like to fail at Apple. Not sure how fact based it is, but it makes you think about the challenges of managing risk and failure.
If you’re making too many mistakes, your company might not be around in a year. On the other hand, if you aren’t making any mistakes, you probably won’t be around in five. Why? Because making no mistakes means you’re avoiding risks entirely. Why is that so bad? Because risk is connected to reward. If you’re not taking risks, someone else is, and when they succeed, they’ll be ahead of you.
If you’re a manager who likes to chew out your management buddies, think about how that behavior is replicated by others in the organization. After all, you’re supposed to be some kind of role model.
Speaking of Apple, I also found a piece on Fast Company about the ever-accelerating smart phone wars.
Telling Stories Together
The next writer out also has a last name that starts with a Y: Adam Yuret. Adam shares the insights he’s gained after taking Elisabeth Hendrickson’s Introduction to Acceptance Test Driven Development. Specifically, Adam talks about the value of doing story workshops. In the end, Adam writes, we might not end up with a story chiseled in stone, but the shared understanding gained from a story workshop should reduce time lost to major changes and confusion later.
I couldn’t agree more. While I have only tiny experience from ATDD (a client of mine recently chose to go this way), I have lots of experience of facilitating workshops of different kinds. In my experience, the value of effective workshops is dual. First, we get the value of clarifying assumptions and laying out a clear plan of attack together. Second, we get the value of realizing that we’re actually in this together, and that we have the potential to work as a team. It’s plans and morale, both for the price of one.
Back in the eighties, my best friend’s dad sometimes took his Mac SE/30 home from work. We ended up exploring it’s every nook and cranny. Probably the best piece of software on it (aside from the game Dark Castle) was HyperCard. It was the precursor of the wave of multimedia development environments that rolled in during the nineties.
HyperCard was awesome. You could easily create interactive storybooks and simple applications with scripting. Ever since then, I’ve been waiting for a replacement with HyperCard’s impact. This, of course, is when more experienced software people feel obliged to comment that ”that myth of making everybody a programmer has been around since the beginning of computer’s”. Well, maybe it has, but it won’t be a myth once it’s true. Or, if it really is a myth, I still choose to believe in it.
Why would anyone want a tool that makes it easy to create programs? Why wouldn’t we? With computers, we’re sitting on the most incredible piece of universal machinery ever created. But, for almost everyone, the power of the computer is still locked away behind arcane programming languages.
The untapped demand for accessible development environments is evidenced by, for example, how Excel is frequently used to develop ad-hoc solutions to computing needs. Professional programmer’s would say that’s not using Excel but abusing it, but the fact remains: Excel might just be the most widespread non-programmer’s development platform. Heck, even people who now how to code for real create stuff in Excel, like Space Invaders, for example.
This week, a tweet flew by about something called WaveMaker. It sounded like an attempt to create just that kind of accessible environment, so I checked it out, and it turned out to be some kind of browser-based development environment. I just downloaded it now to have a closer look. I don’t think WaveMaker is what I’m dreaming of, however. I managed to create a simple ”Hello, world!” app in a few seconds, but that’s just because I used to be a programmer. All in all, this looks more like a programmer’s IDE than the everyman’s toolbox I’m dreaming of. That doesn’t mean WaveMaker isn’t awesome. It does mean that it’s not what I’m looking for in this regard.
What’s a Test Strategy?
My friend from the AYE conference, Fiona Charles, has a great new article out. It’s called ”Basics Revisited: Test Strategy”. In it, Fiona takes a clear and pragmatic look at what a test strategy is. Fiona takes a stand against huge documents filled with boilerplate text. Instead, she urges us to understand what it means to have a test strategy:
”A test strategy is the set of big-picture ideas embodying the overarching direction or design of a test effort. It’s the significant values that will inspire, influence and ultimately drive your testing, and the overall decisions you have made about ways and means of delivering on those values.”
Fiona also asks us to think about the medium we use to communicate our strategy:
”I have used one or some of: a mind map, sticky notes, a drawing on a board, a colorfully highlighted diagram, an outline document, or presentation slides. The choice depended on the organization I was working with and the nature of the test. Whatever medium you choose, it should work as a tool you can walk around with to talk to stakeholders, or use in meetings to promote discussion.”
Also on the testing side, I found this neat report from StarEast 2011, written by agile tester Lisa Crispin.
Finally, Andy Hunt has some good advice for advanced agile practitioners: stay uncomfortable. If you’re starting to think you know what this is about, that may mean you’ve stopped thinking hard about how to developer even further.