Usable Software Design - a federating concept

Design is not just what it looks like and feels like. Design is how it works - Steve Jobs

Alexandru Bolboaca applies ideas from general usability design to code :

Software design is the only type of design that seems to be userless. After all, the end-user has no idea how the software works and doesn’t care. All they do care about is to work ...Software design is not userless. The user is the developer that will have to change the code after you do....

A common goal for the team

This struck me as a very powerful way of framing discussions with software development teams. I get to work with development teams for a few months to help them adopt XP practices that are useful in their context. Typically the hard part for teams is learning TDD, object oriented programming*, SOLID principles, Simple Design etc. In my early days as a XP facilitator I often met resistance and indeed many of my friends in the Software Craftsmanship community still meet this kind of resistance, often to a point where their progress has come to a total standstill. I hope I’ll find energy to explain in detail how _I_ am changing in order for colleagues to find less need to resist my ideas, but for now lets talk about how the concept of "Usable Software Design” can be used to guide change in a team. 

First of all lets see what "Usable Software Design” might mean. Alexandru states three things : Clarity, Consistency and Minimize the unexpected. I decided to try this idea with a new team I just started working with and I reframed the ideas to “We all appreciate workable code and design … it'll have a positive effect on our performance... So what is it that makes the code easily workable?" Here's what I suggested

A team agreement to try

Usable Software Design means to us that

1. It is written for developers to read
2. It is easy find where to modify the code
3. Any modification has a minimal ripple-effect 
4. It is easy AND fast to validate that we did the right thing
5. We don't have to do similar modifications in several places

NoDeveloperCanDisagree™! Indeed this time everyone nodded and listened intently. How we get there doesn’t matter to me as long as we get pretty close. And this is extremely important, we’re ONLY talking about desirable outcomes, not how to get there. In particular if we want to keep the federating force we have to welcome ANY SOLUTION that brings those desirable outcomes. 

Now let me dig in to 4. because it has some unexpected consequences. I currently know of only a few ways to get this. In no particular order a) being able to launch and interact with the application in short cycles, b) automated tests at various levels, c) manual testing and shipping shortly after development. Look ma’ it’s not only automated testing that requires isolation from non testable dependencies, a) requires it too, even c) to some extent. Reasoning like this even developers who don’t care much about automated testing want pretty much the same thing as someone like me! It has a federating effect.

5. is going to make us limit duplication, even across process boundaries, to a bearable level. 3 is likely to bring SOLID principles. 4 is likely to favour TDD, and TDD will help 2, 3 and 5. 

Conclusion

As a team we agreed to try this, and because it doesn’t enforce any specific solution as TDD, DDD or SOLID it means we can evaluate any development with pretty much the same yardstick. All that matters to me is that we nail 1-5 because then it’ll be pretty nice to code in that team regardless what tools we use.

And now I'm off to Vienna to train in doing Usable Software Design with a few hardcore Craftsmen!
*Yes even Object Oriented programming is not mastered to the extent that is needed by far, at least in iterative development.

Image http://hotinfb.com/post/agree/