August 02, 2016
From, with love.

Don't Solve Imaginary Problems

Hi everyone,

One of the most common causes of scope creep is something I call imaginary problems. Imaginary problems are often described using phrases like, "what if one day someone wants to..." and tend to trigger software engineers' creative brain to try to plan for all possibilities. However, continuing down this path is a bad idea. Why? Because you will never know if you've solved the problem correctly.

Imaginary problems can't be solved because you don't have a use case to validate them against. How will you know if you're successful? How will you know if you've failed? Likely, only when someone with an actual use case tries to use what you've created and finds that it doesn't work. This outcome, of course, is easy to predict. You didn't have a use case and tried to imagine one. You ended up with a "good enough" solution because there was no pressing need for it. Your scope increase had no payoff: the extra work isn't useful for anything.

You should only ever build solutions for clearly-defined problems because that's the only way you'll know if your solution works. When I tell this to less-experienced software engineers, they are typically confused. It seems like software is always being built for the future, why wouldn't you try to imagine how the software will be used? Yes you should, and that's where a good architecture comes in.

Good software architecture provides space for functionality that doesn't yet exist. Ideally, you're writing small pieces of functionality that solve very specific problems. Those pieces can then be inserted into the architecture along with a lot of other small pieces to form the application. (This is an idea I spoke about in my Scalable JavaScript Application Architecture talk.)

If you look at any sufficiently large application, you'll see this pattern repeated over and over again. Applications cannot know what their requirements will be in the future, and attempting to guess is almost always a waste of time. Instead, focus on building small things that solve specific problems, and make sure the application architecture allows for an infinite number of small things. 

Be well.

This newsletter is subscriber supported!
There are many ways to support it: Leave a tipbecome a patron, or buy a book.

Recommended Links

Debugging Node.js Nightlies with Chrome DevTools (article)
One of the coolest new features coming to Node.js is the ability to debug directly in Chrome DevTools. The DevTools team recently submitted a patch to Node.js that allows is to communicate directly with Chrome DevTools. While only available in nightlies right now, this feature will eventually make it into Node.js.

Dominant Colors for Lazy-Loading Images (article)
Have you ever noticed that Pinterest image placeholders have a color that seems to match the image that is about to load? It's a really nice user experience and not too difficult to achieve. This article describes techniques in both Node.js and PHP to achieve the same effect on your site.

A Comprehensive Guide to Font Loading Strategies (article)
Using web fonts is simultaneously very easy to get started with and very complicated to master. Flash of unstyled text (FOUT) is a primary concern and there are many different approaches to solving this problem. But which is best? This extensive article covers the current solutions along with pros and cons for each one. You're sure to pick up a new trick or two just by reading.

Moment of Zen

"Engineering tradeoffs and stupidity are often indistinguishable if you're unaware of the tradeoffs."
- Eric Elliot (on Twitter)

Recommended Book

For a lot of my life, I dealt with a high level of anxiety. Some of that was of my own making while other parts were related to Lyme disease. I came across Feel the Fear and Do It Anyway during a particularly tough time. The title really grabbed my attention and I read it attentively. The message of the book echoed something a therapist had told me: it's okay to feel nervous or afraid. That doesn't mean there's anything wrong and it doesn't mean you have to make the feeling go away. You can actually keep moving forward even while feeling this way. Yes, this book is a bit stereotypically self-help in nature, but I found it to be a useful study in the art of just feeling whatever it is that I'm feeling and finding a way to proceed.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...

Books I've Written


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences