My childhood home has two bathrooms upstairs, one in the hallway for everyone. And one in the master bedroom. They shared common water lines. If Mom was taking a shower in the master bedroom and I didn’t hear the water running, I’d hear about it when I flushed the toilet in the hallway bathroom. We shared a common interest, needing…
Category: Contemplations
Worthwhile automation
In many situations, software exists to automate what would otherwise be done manually in business. For example, calculating interest on bank accounts. It also enables us to do things we’d never be able to do by hand. By investing in automating the mundane, we’ve created tools that open up new opportunities. Things not possible, nor fathomable before. Between manually doing…
The mythical developer bias
Every once in a while someone brings up the subject of developer bias. This usually happens in the context of a conversation about software verification. How do we verify the software does what we need it to do? By developer bias, these individuals are referring to their perception of some universal law that developers can’t ensure the software actually works.…
Progress isn’t that complicated
Task counts, burndown charts, measuring velocity, estimates, backlog size, estimated hours, completed hours, use cases remaining, number of stories done, number of stories being tested, etc. There are so many ways people try to measure and quantify expended effort and compare it to estimated remaining effort. Often in an attempt to convey some indication of progress. Most of the time…
On going development and taking breaks
It’s great to move to a model where we can adapt and learn as we develop software. Instead of trying to specify everything up front for the next years work. In making this transition, it’s important not to swing to the opposite end of the spectrum and suffer the consequences of under commitment. Fortunately, projects are a great way to…
How to elicit cohesive software verification
Software verification is no simple task. How do we know the software does what it should do? Or better yet, how do we know the software does what we think it does! Perhaps even more challenging, what do the various individuals involved in creating the software think it should do? What do stakeholders expect? What do developers think? Testers? What…
Hoarding features
A few weeks ago I stumbled on an article about clutter. Apparently hoarding is now considered a psychiatric disorder. I wonder what took so long to come to that conclusion. The article referenced the DSM-5, released in 2013: hoarding, is now a distinct psychiatric disorder, defined in the new Diagnostic and Statistical Manual-5 as “persistent difficulty discarding possessions, regardless of…
So that shouldn’t be optional
User stories are a popular technique to organize software development. While many use them to record future work, they’re much more valuable as a means to enable effective communication. By using the As A, I Want, So That format, we capture three important things: who, what and why. The latter is what matters most. We can alter who and what,…
Downstream cost of interfaces
Last week I mentioned the consequence of not fixing problems upstream. When we design software to be dependent on other systems, those systems become upstream dependencies. No interface to any system is “perfect,” there’s no such thing. But there are many systems that have interfaces that require excessively nuanced interpretation by downstream systems. This can happen for any number of…
I think I need
“I want”, “I need” Implicit in both statements is a crucial word. “I think I want”, “I think I need” The fact that we want or need something implies we have thought about it. At least long enough to utter the words. But it doesn’t imply how much thought, nor how rational. “I want” is much more powerful than “I…