New idea in Usable Software Design: Mistake Proofing Design

[AlexBolboaca]

Hi fellow craftsmen,

I'm continuing the series on Usable Software Design with a new topic. None of us likes to make mistakes when writing code, yet mistakes still happen. This is a problem from an economic point of view - fixing mistakes can prove costly- but I'm more interested in the user-centric view. In this case the developer-is-the-user-of-the-design-centric-view.

I tried in this blog post to detail 5 steps to mistake proof software design so that it becomes more usable for developers. Here's the link: http://mozaicworks.com/blog/5-steps-to-mistake-proof-software-design/.

As always, I appreciate any feedback, comment or idea. Is this topic interesting for you? Why not? What would you like to learn about it?

Thank you, and happy crafting,
Alex

[Tim Ottinger]

One of the things that we have to understand about software is that software is a matter of making and recording decisions -- from what kind of a variable to use and how to name it, to how to use classes and libraries, to technical details about how to lay out code for the optimizer/pipeline/etc, to how to lay out data for map/reduce queries, to how to present and collect data from humans, to the ever-important issues of prioritizing and slicing features to ensure we don't build unwanted code. 

This is difficult because all the systems we work in are bigger than our own craniums. 

All defects in software are decision-making defects, which means that the single greatest thing we can do to avoid defects is to create the conditions for making better decisions. Those conditions seem to be feedback, safety, focus on learning, short reach, and ever-simpler design. I applaud your efforts to document the lattermost.

These are good steps to take, and I endorse the article (with of course some additional notes about pairing and test-first), but I would like to amplify that no amount of mechanical design will ever be enough. We have to change the human system so that learning is easy and fast, and failure is local and safe, feedback is immediate, and the inject-detect-correct period is as short as humans + machines can make it. 

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship.
For more options, visit https://groups.google.com/d/optout.

--

Tim
----
http://www.industriallogic.com/