Engineer Thinking and the Art of Software Engineering
Matt Gemmell brings up an interesting point in a recent blog post regarding user choice and defaults in software design.
But a problem arises when you allow precision-based design principles to hinder user experience. All too often, when faced with a decision about how to implement certain functionality, engineers take the extreme position that:
- A feature must be exactly what 100% of users want.
- If the above isn’t true (and it almost never is), the feature must be configurable.
This binary approach is gravely wrong, and unjustly offloads decision-making onto the user of the software. We’ve all seen where this approach ends up: multi-row sets of tabs, scrolling panes of checkboxes, nested radio-buttons and a general overload of configuration.
He goes on to talk about technical complexity and the responsibility of software to “mask uncertainty and to make the effort to provide a sensible default behavior.” However, as the post progresses, it evolves into an article that talks about the art of software engineering. One paragraph in particular really stood out to me:
It all comes down to a question of art. Our art (that of software engineering) is not in making it work. If you see it as a significant success that you managed to name some methods, or write code that compiles and runs (or implemented a heap sort, or found the bounding box for a set of points, or parsed some XML), then your career goals are low indeed. Anyone in this industry can do that stuff, including any reasonably proficient final-year undergraduate in Computing Science. That’s core-skillset, vocational learning. You’re not aiming high enough.
This got me to thinking: how often do I put ultimate importance on making something work? I’ve always been a proponent of attention to details and good UI design, but I’ve certainly been guilty of, as Matt puts it, setting my career goals too low. Something to think about.