Dave Smith wrote about his new camera, justified on the basis of recording whiteboards after meetings, triggered this post. In his post, he states,
“The one problem is the flash, which tends to white out an area of the whiteboard, requiring either multiple shots or shooting off-center, which leads to odd looking results.”
On the Test Driven Development YahooGroup, Alan Baljeu asked, “It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature…. And by not considering those things, you introduce bugs into the software.” In response, he got two types of advice. One was specific suggestions of software construction techniques that can reduce the occurrence of errors by reducing the number of places that need to change when adding a new feature.
The second type was general testing advice. Alan admitted, “I don’t see a way to properly identify what new behaviour will need to be covered. I want to be sure I’m not forgetting cases, but currently I’m overlooking too many of these effects.” In other words, the current test coverage is not catching all the errors. Read More
Matt Heusser has just published a post about standards. In it, he says
So, when people rush to standards, I hold back a bit. Having a standard means saying “We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things.”
I, too, have been puzzled by the rush to standardize. Read More
Ok, maybe you already know these things. I’m a pretty open person so there’s not much unknowable about me that I know of. But Johanna tagged me to say 5 things, and these are the ones that came to mind:
I saw this question in a blog post by Mark Schenk:
About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks ““ we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.
That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.
They all immediately agreed and thanked me for the information. Well, not exactly. Read More
I attended a session with Naomi Karten at the AYE Conference last Fall, so I knew she had a lot of good things to teach me. In spite of those high expectations, I was blown away by this book. In fact, the only negative thing I can say is that there’s material for two or three books in here. Having read through it once, I know I’m going to have to re-read it in sections. Read More
What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.
That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations. Read More
I’ve always been of the opinion that software construction is not like physical construction. Or, rather, that the construction part, analogous to hammering two-by-fours together when building a house, is running the compiler. And, of course, you rarely tear a house down and rebuild it over and over, until you get it right. Therefore, software development is nothing like mechanical construction.
Except, of course, when it’s very much like mechanical construction.
Read More
Matt Heusser just posted a blog entry on conferences, where he makes excellent recommendations. During much of my career, I relied primarily on magazines and online communications (remember CompuServe?) to broaden my horizons. These were worthwhile, but are no match for face-to-face communications. Read More
A Steering manager uses the Law of Diminishing Response as a guide to successful control interventions. When you consider adding some pressure, the key variable to monitor is not people’s performance, but their responsiveness. How are they responding to the existing pressures? When they hear of a new “challenge,” do they drop their head a quarter of an inch and mumble an acceptance under their breath? Do they become annoyed and give a hundred reasons why it can’t be done? Do they show external signs of panic? These are all signs that they’ve reached the point where responsiveness has gone negative, yet they are unable to control their own response.
On the other hand, are people alert and genuinely enthusiastic, able to ask penetrating questions that need answering before accepting the extra work? Can they consciously trade off less important work for high-priority assignments? These are signs that their responsiveness is still above zero, so it’s okay to pile a little more fuel on the fire; but don’t make any assumptions about next time.
Jerry Weinberg, Quality Software Management: Systems Thinking
Last month, Dmitri Zimine posted a small rant against context switching. Read More