I’ve been having fun this week watching some conference talks about my current favourite language, Elm, at Elm Europe 2017. And I enjoyed seeing an important idea discussed—important not just for coding, but for product and project development generally. The lesson is: solve the actual problems experienced by actual people. Don’t generalise—at least not without a huge amount of real data—and don’t assume. The specifics of individual problems are really important, and they can’t be overlooked.
In one talk, Elm creator Evan Czaplicki asked how one might create a data structure for a selection list. He gave two examples: a list of app settings (email notifications, video autoplay, and use location), and a list of fruit that might be bought online.
A typical developer might well treat them as different instances of the same basic idea, and therefore use the same underlying data structure. But Evan showed that the context for each list would be different, leading to different requirements and therefore different underlying data structures. For example, app settings might have sub-settings such as autoplay being an overarching option, but also allowing fine-tuning individually for audio and video. A list of fruit to be sold might further require special offers to be bumped higher up the list dynamically, depending current stocks and prices, and we might want to limit demand and so allow only a limited number to be selected at any one time. These different requirements lead to different solutions. We could build a structure that handles both of these, but it’s probably excessive work, and it would be much more appropriate to treat them differently.
In a later talk, Greg Ziegan discussed a less theoretical example. He talked about how he (initially) failed to build a general purpose package for something remarkably similar:
Some pragmatic Elm developers told me at an Elm meetup why don’t you just build it for you, for what you’re going to build right now? [But] I just wanted to build for everyone. And that was good advice, and I should have followed it.
He went on to describe how he built a package for an assumed general need, without considering any specific use cases. When his first users came to try it he discovered he’d made a key design decision which meant it was useless to them. He had to start again.
This isn’t just good coding advice. It’s good advice for building a product or project, or even a business. The nitty gritty details of real users’ real problems are important to understand, because they influence the details of the solution. It makes all the difference between a Phase 1 release that genuinely solves problems and one that just misses the mark.
niksilver.com 