So, I’m working on a side project (as one does), and reach the point in development where I need to be able to take a tree of objects that all share a common base class and persist them to and from disk.
I prefer using plain text files to binary (for a bunch of different reasons, most of them enumerated in the original The Pragmatic Programmer book), so the problem really boils down to:
At runtime, I need to be able to convert a string containing the name of a class into a pointer to an object of the corresponding C++ class.
If you do like I did, and go to the shelf to see what the old Gang of Four Design Patterns book has to say on the matter, maybe you’d have been underwhelmed, too. (more…)
Be More Than Just A Code Monkey
I wrote this book because I believe the shift away from “programmer as coding specialist” is inevitable. If that’s true, then our entire field will need to prepare itself for the not-so-distant future where “programmer as skilled solver of ordinary human problems” becomes the norm.
— Gregory T. Brown
I picked up this deceptively slender (~115 pages) book after reading an article about it on the O’Reilly site a week or so ago that said “it’s sort of like The Pragmatic Programmer for a new generation.” Given how important that book’s been for me as a developer (it’s in my periodic re-read pile, along with Code Complete, the GoF Design Patterns book and Knuth’s Literate Programming), it didn’t take much thinking before ordering a copy.
A few weeks ago, I posted a review of the recent book on building connected products from O’Reilly. I also have a few more books on the shelf here that touch on this area from a slightly different angle.
The Best Interface Is No Interface
I became aware of Golden Krishna, the author of this book when I attended his panel criticizing the use of dropdowns at SXSW 2016. The content in this book predates that panel by a few years, originally presented as a keynote at SXSW 2013.
The basic thesis of the book is that it’s variously easy, lazy, and sloppy to always try to address the problems we’re solving through technology by slapping a screen-based interface on top of things. Early in the book he gives the example of a keyless entry system advertised by BMW, that requires the following 13 steps to occur between a user walking up to her car and actually opening the door:
- Walk up to my car
- Pull out my smartphone
- Wake up my phone
- Unlock my phone
- Exit my last opened app
- Exit my last opened group
- Swipe through a sea of icons, searching for the app
- Tap the app icon
- Wait for the app to load and try to find the unlock action
- Make a guess with the menu and tap “Control”
- Tap the Unlock button
- Slide the slider to unlock
- Physically open the car door (my goal)
Compare that with the obviously better sequence
- Walk up to my car
- Physically open the car door (my goal)
…which is how things behave on recent Tesla models (with the added coolness of the door handles changing from being completely recessed into the body until someone tries to open them).
The book’s 21 chapters thoroughly outline the problem, three general principles to follow in addressing the problem (“Embrace Typical Processes Instead of Screens”, “Leverage Computers Instead of Serving Them”, and “Adapt to Individuals”), and some of the challenges that make this approach to design not quite so easy.
Mining a similar vein is David Rose’s 2014 book Enchanted Objects:
Some believe the future will look like more of the same—more smartphones, tablets, screens embedded in every conceivable surface. David Rose has a different vision: technology that atomizes, combining itself with the objects that make up the very fabric of daily living. The Enchanted Objects of fairy tales and science fiction will enter real life.
The opening paragraph of the book’s prologue could almost have been extracted from somewhere in ‘The Best Interface is No Interface’:
I have a recurring nightmare. It is years into the future. All the wonderful everyday objects we once treasured have disappeared, gobbled up by an unstoppable interface: a slim slab of black glass … its face filled with tiny, inscrutible icons that now define and control our lives.
These two books work together as great complements; however, Rose’s focus on building Enchanted objects alters the tone of things quite a bit. Recurring themes and references take that idea of Enchantment quite literally, as he looks at fictional magical artifacts from the Harry Potter universe.
Besides many case studies of examples that illustrate his premises, he provides a pair of frameworks for thinking about systems that can be used as a designer of enchanted objects:
Six Human Drives
In these chapters, Rose develops dialectics between fictional enchanted objects (e.g., Dorothy’s Silver/Ruby slippers) and an analogous real one (in this case, the Nike+ shoes). He delineates six human drives that can be augmented or addressed through enchanted objects:
The Design of Enchantment
This set of chapters discusses opportunities and techniques for engaging more of our users’ senses through system design, rather than requiring the user to focus on a glass slab. He calls for a careful use of ‘subtle and subliminal phenomena’. He calls these out as the ‘Seven Abilities of Enchantment’:
Optimism and Humanism
Especially when considered as a pair, even though there’s much in these books that’s deeply and sometimes harshly critical of products that have been widely lauded, I see these books as extremely optimisitic visions of the future than not only should be, but that actually can be.
I’m not sure which will prove to be more difficult in practice:
- Learning to put these kinds of approaches and principles into practice when desiging systems
- Convincing the stakeholders on our projects that we can use these ideas to build better systems that adapt to their human users instead of continuing to require the opposite.
One could say that the ideas behind these ideas go back a long time, popping up in books like Donald Norman’s classic “The Design of Everyday Things”, “User Centered System Design”, or Jef Raskin’s “The Humane Interface,” but those were all written in an era when the idea of tiny battery-powered computing devices that are orders of magnitude more powerful than desktop/workstation machines of the era was still purely speculative.
The future is finally getting here, let’s try not to mess this part of it up.
A Book Review & Call to Arms
We’re pretty clearly on the cusp of an era where much of what we know about building software systems is wrong. As devices become smarter and networked (or dumber and networked, which may end up being equally important or more important in the long run), as people who design and develop the software systems that monitor, control, or otherwise interact with these new kinds of devices, we all need to acquire different sets of skills that are currently rare, and apply our old habits and knowledge in different ways than we’re used to. (more…)
I used to do this more frequently than I have been — here are some posts and articles that have occupied open tabs in my browser for much of this week:
Two Views of Technical Debt
Earlier this week, we had an interesting discussion in one of our internal discussion forums on this Medium piece from 2014 talking about the difference between Technical Debt and just writing bad code: (more…)