Bass-ackwards
Mar 9, 2010 In Process By Tim AidlinWhich comes first, the problem or the solution? IMHO, obviously the problem. So why do we so often develop technology solutions and then find a problem for them to solve
I recently had a conversation with a random developer I hadn’t met before. Within a minute of our introduction, he had launched into an enthusiastic, but very misguided, demo of a new technology he was excited about.
Why misguided? The technology in question was meant to solve a problem no one had.
When he asked me what kind of application or site I thought could use this technology, my first thought was, “Again, finding a problem for a solution. Exactly the opposite way I generally try to work on projects.” But instead of saying that, I asked:
“What problem does it solve?”
“What do you mean? You could move around data, put it here or there and connect it—all sorts of things.”
I said to him, “I guess I work a little differently. I try to think about the problem I’m trying to solve, and don’t think about the technology we’ll use until much further in the process of designing the spec.”
“But this technology could really be used in all sorts of applications,” he said.
“Totally. It’s super-cool,and I’ll think about it when I’m specing out my next project.”
“Maybe you can build a project around this technology.”
“Building a product around a particular technology sometimes works,but we find our most successful projects start from trying to solve a problem first, and applying technology to it second. It’s kinda like showing engineer a carburetor and telling him to build something around it.”
This conversation struck me as a fairly extreme rendering of a common design snag: building for technology, not to solve problems. You see this all the time, and not just in software or Web site design. I’ve seen it in landscape design, city hall, and the day care, too. What are your favorite examples of solutions without problems? Leave a message in the comments below.
Follow the Conversation
17 comments so far. You should leave one, too.
I find that I work FASTER and more EFFICIENTLY when I''m working to solve a clearly defined problem. I relate it a lot to being an artist. If you are trying new techniques, or playing with software it''ll take you forever to get a "finished" product (if at all), but if you have a vision of what your goal (problem) is at the outset, all your decisions will take you toward meeting that goal and not necessarily exploring alternatives.
In contrast, however, sometimes exploring or working to build a solution to a problem that doesn''t exist leads in some very creative directions. You will often end up in a wondrous place if you work this way, but it''s rarely cost effective to do so.
You''ll get this a lot when you have your business owners trying to be the designers. "Make it use AJAX!" "Can this use Flash?" "I heard about this Web 2.0 stuff...can we use that for this?"
Most devs are guilty of this at one point or another. I know I am! But it''s not a bad thing, it keeps your skills sharp and your enthusiasm high.
You know the old saying, "If all you have is a hammer, everything looks like a nail?" Well, eventually you FIND something to nail, and it''s good to have that hammer when you need it.
Sadly business people are often so focussed on a specific issue that they fail to see related opportunities that technology solutions can uncover.
You nailed it.
What problem does a web browser solve?
No, really. Think back to 1993 and try to come up with a plausible user story.
I''ve built (and rebuilt) lots of projects around technology. XHTML ...and then HTML5; CSS2.1...and then CSS3; come to mind. I''ve built templates, thinking I MIGHT use them later. I build websites AROUND the templates. I have numerous little CSS and javascript toys, built up over the years.
And, yes (if this is further required by what you''re saying) my possession of these tools has motivated me to create things around them BECAUSE I have them, and not just wait until I need them.
Parts is parts.
I do believe that we need both types of people. People who build toward a specific problem. And people who build technology that just does stuff that is really cool.
The reason the latter is important is because sometimes the people who can build these really cool technologies aren''t the same people who are good at finding problems. But if they get that technology in front of the right person, that person may say, "Wow, this would be perfect for XYZ!".
Thanks for all the comments, y''all.
I absolutely agree that it''s important to have top-notch developers and designers creating things "just because they''re cool," and I''ve personally benefitted by using these technologies. And some of them are just fun or beautiful, which is totally fine.
I do find, however, the tools and tech I keep in my pocket, as fjpoblam suggests, are those that, again, solve specific problems. JQuery datepickers, for instance.
Our lab project, Glimmer, is a good example of developing tools to solve a specific problem. We saw that there were designers out there who would benefit from a visual way to build JavaScript animations without having to actually code the JavaScript. We then focused on the scenario, developed personas, etc ...
So, rather than decide we wanted to create a cool WPF application that did something awesome, we started with the problem, and developed the solution.
Great article Tim, with some very interesting comments! I agree with you that at least for developers the problem should always come first. I''ve seen way too many projects that are on the bleeding edge only because the lead developer wanted to be there! I love Silverlight, WPF, Azure, and SaaS, but there are plenty of "problems" that could be solved with simple 2-tier applications, pick your front end and a database, and would be fine. As developers we need to be mature enough to use the best approach to a problem and not just use a new technology so we can put in our our resumes. Just my thoughts. Once again, great article.
Well said. I absolutely agree - build something to solve a problem not the other way around. That takes real vision to do well, and a knowledge of both the business and the technology; a combination that can be rare in a single person and needs to be solved by having good communication between the technical person and the customer - isn''t that where all or successes and failures are made in this industry?
Very interesting article, but sometimes there is no problem until a new technology comes along to shine a light onto something that people didnt consider a problem in the first place (which is where we find our company).
Lets take web browsers for example: back in the day, the web browser basically had an address field. Noone knew that opening websites in multiple ''tabs'' was a better solution than keeping multiple ''browser windows'' open, until someone introduced tabbed browsing (i think it was opera).
The same could be said for the browser search field. Although it didnt specifically fix a problem (users could simply type http://www.myfavsearchengine.com into their browsers), the search field did unlock new usability enhancements to the browser.
So, how do you address a problem that people do not yet consider a problem if there are other (albeit less usable) solutions? This may be just a game of educating users that the new approach is better.
-=Vin
I agree with you 100% Tim. While there have been some technologies that aren''t created to solve any problem (cough Twitter cough), the vast majority of applications have a goal in mind.
As far as the browser comments go, I would argue that there is a very obvious problem.
Problem: Users want to view documents posted on another computer .
Solution: HTTP and all the software that goes along with it.
That leads to the another issue, as developers we often fail to recognize problems that need solving or have already been solved.
There is nothing I dislike more than when a client wants to use a technology or certain core method because it looks cool rather than actually being valuable to the project.
I have had clients lay out their entire website ideas based around a jQuery accordion, or a Flash gallery. Never taking into consideration the actual message those pieces would deliver, just doing it because it was cool to them.
I agree that I like to experiment and use new tools when I can, but not at the expense of the overall project or message.
Omg, I didn''t know that we often develop technology solutions and only then find a problem for them to solve. Maybe it originates from lack of creativity, or the need to bring results the fastest way possible, thus going after quantity rather than quality. But hey",":http://www.electricgriddlereviews.net scientists today who are working on the The Large Hadron Collider in Geneva also don''t know what the problem they are trying to solve, but most scientists agree that the knowledge of the project can be invaluable and may affect all aspects of our life.
I recommend reading the essay "The Two Cultures of Mathematics" by Timothy Gowers. You''ll quickly see an analogy between Gowers'' two cultures and the two approaches to software development you mention in this article.
Your favorite search engine will lead you to a PDF of the essay if you''re interested.
I actually did a search for that essay and found it as a downloadable pdf
http://www.dpmms.cam.ac.uk/~wtg10/2cultures.pdf
there''s a few other links with the same file that one seemed the best of the bunch
First, let me direct those of you who speak Belorussian to check out the great translation by Paul Bukhovko: http://www.fatcow.com/edu/bass-ackwards-be/
Secondly, thanks all for the great comments. I think one of the common threads I''m seeing is the tension around when the problem is identified as opposed to the solution. Vin writes above about people not knowing they needed tabbed browsing until it was invented and available. I counter that tabs were introduced specifically to solve a problem ... maybe most users didn''t know it was a problem, but that''s what being innovative means to me: seeing a *problem* that people don''t see and solving it.
Another example from above is the Large Hadron Collider and the experiments they''re doing there. Again, I disagree that the problem hasn''t come before the search for a solution in this case. Now, the problem might be *very* amorphous (ie., what''s Dark Matter?) and we understand that we must take steps to understand and solve the problem, but that''s the goal, right?
In any case, I think this is a good discussion to have and really welcome your continued feedback.