In software, you wind up spending most of your time solving easy problems. Problems that have been solved before and, thanks to Google, have solutions available in an instant. Thousands of well-defined, no-risk, completely solvable problems.

Virtually everything having to do with a user interface, if you’ve seen it done before, is “easy.” Gmail has a drag-and-drop attachment feature, so clearly that problem has been solved. Facebook has a live-scrolling ticker of events – piece of cake, just do what they did. Also, anything that has an open source solution is easy. Thank you Solr/Lucene, search is easy. Thank you Hadoop, doing computations on huge datasets is easy. Thank you Ruby on Rails, building complete websites can be done in 15 minutes.

I actually do think all of these things are easy, to the extent that “easy” means you’re going to be able to solve them without needing to hire an expert and you won’t need to dust off your old Algorithms textbook at any point in the process. But there are a few things “easy” doesn’t mean:

Easy != Fast

Just because you know how to do it, that doesn’t mean it can be done quickly. We all know how to mow a lawn. Can you do 10 acres in 5 minutes?

Depending on the problem you’re solving, usually one of two reasons explains why Easy != Fast

1. The problem is clear, but tedious to solve

Building a sign-up form is simple – some text boxes, and a submit button. Of course, what sign-up form would be complete without validation, autocompletion/correction, tooltips, markers for optional/required, anti-bot/spam protection… and each of those things is easy too, but you’ve just got a lot of lawn to mow. (photo from: smashing magazine)

2. The problem is solved by a 3rd party tool, and it’s got it’s own… problems

Solr does, in fact, make it very easy to build a search engine that produces fast, relevant results. Now, bone up on schema.xml, db-data-config.xml, the various query parsers and their associated syntaxes, then review what the best/current libraries are for whatever language you’re using. It’s true, you don’t have to write any algorithms. You’ve also saved yourself time over building this thing from scratch – no question. But, you’re still about to spend a considerable amount of time on this.

Easy != Well Defined

There are still the fundamentals of software engineering at play. The example of the registration form above was also partially an tale of vague requirements.

“We want a sign up form just like foo.com has” is the easiest way to spec a feature – you just point to something else and say “do it like that.” Even though that may seem less vague than “we want a sign up form”, unless you truly understand the thing you’re referring to you may have accidentally added more requirements than you meant to. Did you notice the foo.com has a live, password strength calculation and doesn’t let you sign up unless the password is strong enough? Did your developer just lose a few hours researching the best plugins/schemes for that, then implementing them, all to build something you didn’t actually need?

Easy == Solved, but what does Solved mean?

Google makes billions of dollars on CPC ads. Paypal makes billions of dollars in processing payments. They each have plenty of competitors doing the same things, so the technologies behind processing CPC ads and sending payments are surely mature, and these are cases of solved problems.

But how much time and effort do these companies spend fighting fraud every day? Google has an Ad Traffic Quality team. Paypal has a Fraud Investigation Team.

Sometimes a solved problem only looks that way because there is a metric ton of ongoing work making it appear that way.

Want to know why Nordstrom has beautiful, consistent photography of all of their products on their shopping pages, with the ability to zoom in on, and see a product at multiple angles? Solved problem: simply unbox every single thing you sell and photograph it the exact same way from the exact same angles. After that little exercise, adding a zoom feature is pretty straightforward.

Piece of Cake

I don’t object to using the word “easy” in software. It’s useful to acknowledge that something has minimal technical risk. But, be careful when it creeps into discussions about scheduling or operations. Time is not measured in units of difficulty.