In a recent post for Exit Event, Blake Callens, lead engineer at mobile commerce startup SpotTrot, borrowed from former Pixar storyboard artist Emma Coats’s now-famous list of 22 storytelling rules to discuss some wisdom for developers. His conclusions tapped into some of the important broader discussions going on in the world of development and offered some useful advice for engineers looking to improve the overall design of their products. Three tips that stuck out include:
1. Keep the audience in mind: Just as storytellers need to focus on what’s interesting to the audience rather than pursuing what’s fun for them to work on, developers will benefit from sticking to solving broad problems and fulfilling the core purpose of their software, Callens noted. Rather than getting bogged down by adding features, developers should think about what they can do to make the program work for the users. This ties in some other storytelling rules, too, which are that users will see programs as journeys to be navigated and that they will value the most economical version of those journeys. In other words, the developer has a burden to keep things simple from a user perspective.
“Simplicity is the key to successful software,” Callens wrote. “Refine the program down to where it takes no more than a couple clicks (or touches) to complete any given task, regardless of how much work the back-end is doing.”
2. Write it down: As Coats explains, getting an idea on paper makes it easier to start revising it. When it sits in someone’s head waiting to be perfect, it will never go anywhere. The push for developers to document more of their work, particularly during the early design phase when requirements are being defined, is ongoing in the software community. Actually writing out design goals and drafting code is essential for figuring out what will work and generating a greater sense of clarity for the product, Methods & Tools editor Franco Martinig wrote in a recent blog post.
“For me, the first benefit of writing is to validate if things are clear in your mind,” he explained, critiquing the trend of agile development teams moving away from documentation. “If you think you understand something or know what the design of your code will be, having difficulty to write it is a sign that maybe you should try to think more about it. The benefits are not in the results but in the process. It is the same thing when you try to define acceptance criteria for a requirement. If it is difficult to write a description or some functional tests for it, then your requirement is maybe not so clear.”
Once a program has been written out in some form, it can be revised through code review and other processes. But if no one gets started with articulating the important ideas, they’ll just sit in someone’s head, like that epic movie idea the one guy on the team is always talking about but never writes.
3. There are no wasted efforts: When drafting a story, it may be best to drop ideas that aren’t working and move on, Coats suggested. The same thing can apply in software development, Callens noted, explaining that feature sets that may seem like wasted efforts now could come in handy when additional components are added down the line.
“Everything in software development is a lesson to be reused later,” he wrote.
Another area in which this can be particularly true – if hard to rationalize, for some developers – is in testing for and encountering bugs. When developers run static analysis tests and discover features contain logical errors or broader design issues, it can be frustrating to have to go back and fix them, but it’s important for organizations not to treat these moments as wasted efforts. Rather, letting developers handle initial testing with static analysis tools is a great way to teach them to recognize and correct mistakes or habits they may not have been aware of.