Waterfall has a bad rap, likely deserved, of over-committing to the minutiae of what it will take to create or modify software over the course of many months and years. For this, and many other reasons, agile development favors change over following a plan. Unfortunately, this often results in a severe degree of under-commitment, the polar opposite of over-commitment. Both…
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…
Leading A Culture Of Effective Testing
Looking to improve how you verify the software you create? Struggling with how to instill the values of effective testing? Check out my latest article featured on InfoQ: Leading a Culture of Effective Testing
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,…
Hourly billing and cost plus pricing aren’t sustainable
I’m obviously passionate about value in software development. Committing to worthwhile results shouldn’t be taken for granted. All too often decisions are made and actions are delegated. Those that act have no understanding of purpose, desired results and the value of those results. They have no ability to correct course to ensure the results are obtained and the effort is…
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…
Downstream cost of feature branching
Earlier this week I mentioned the consequence of not fixing problems upstream. A great example of this is the costs of long lived feature branches or long lived copies of a piece of software. Each copy has a set of isolated changes taking place. Integration is the upstream leak. Inevitably with many long lived copies of the system, integration becomes…
