Sometimes we act as if bugs just appear in our code on their own, but we all know that’s not true. The bugs in my code were written by me. I didn’t mean to write them. I didn’t want to write them. But I did anyway. I remember when I first heard Al Shalloway refer …
Continue reading “What Mr. Robot Says About Bugs”
Read MoreBack in the 1990s, I was teaching a class at IBM’s wildly successful Cottle Labs in San Jose, CA. It was mid-week, halfway through the class, which had been going really well up to that point, when the students coming back from lunch looked like a train had hit them. Moments before they had just …
Continue reading “What Managers Must Understand”
Read MoreI consider myself a supporter of the #NoEstimates hashtag. It’s not that I think estimates are evil, it’s just they’re often unneeded or misapplied. If the effort to estimate a task is equal to the effort required to complete the task then is an estimate worth it? Estimates can be useful for measuring capacity or …
Continue reading “Ideal Days Aren’t Ideal”
Read MoreIn traditional software development, up to half of all development time is spent writing, maintaining, and interpreting requirements. Even more than bugs, requirements are the single largest time sink in developing software. But what’s the alternative? How will developers build what the customer wants if they aren’t told what the customer wants? The full answer …
Continue reading “Requirements Aren’t Required”
Read MoreIn his book *Mythical Man-Month,* Frederick Brooks says to build a system “three times” by designing, implementing, and testing software. But this approach tends to amplify our mistakes rather than allow us to learn from them. It’s based on the false assumption that we can articulate a system’s behavior in the design documents with sufficient …
Continue reading “Build Once Then Enhance”
Read More