Skip to main content

Hammers and Nails: Technology Push Design

"We need to refine our requirements first, before we look at tools." This is a common phrase that I hear. While I sympathize with the sentiment, I think it is frequently wasteful. I suspect that we'd get to the right requirements faster by looking at tools already available in a given problem space.

Pushing the concept further, is it foolish to find a cool technology and then look for ways that that technology can apply to current problem spaces? 

What if you don't even recognize you have a problem space? Without a constant search and openness, we'll miss many serendipitous opportunities.

Here is BYU professor Larry Howell discussing this issue.

I often enjoy doing something ... that is sometimes controversial. In this approach, rather than starting with a need, you start with a new technology and you search to identify a need that it can fulfill. This second more controversial approach is called "technology push design."  
You can imagine the criticisms of this approach. It is sometimes referred as "a solution looking for a problem" or "when you have a hammer, everything looks like a nail." And there's definitely some truth to this criticism. But there are also some amazing opportunities.  
When you looks at the history of technologies that has made a significant impact on society, many of them did not start with a need. They preceded or even created the need.
For example, before smart phones, I never thought, "Gee, wouldn't it be cool to carry a powerful computer in my pocket that could make phone calls, provide hourly weather predictions, be my navigation system, carry all my scriptures, be my alarm clock and my calculator, and have access to limitless information?" Before microwave ovens no one was sitting around thinking, "Oh! Wouldn't it be convenient if I could nuke my leftovers and heat them up in 30 seconds?" No one thought that because it didn't occur to us that such a thing could even be possible. 
Many great inventions are entirely unanticipated before their creation. 

Comments

Popular posts from this blog

The "True Cost" Phantom in Project Cost Tracking

I want to know if I should wear a coat when I go out the door on an unpredictable spring morning. The temperature from the weather app on my phone isn't going to match exactly the temperature just outside my front door, but it will be close enough to make the decision. If the question at hand is whether or not I should wear a coat, it would be a costly mistake to set up an elaborate system of thermometers around my property to try increase the precision of my measurement of the temperature. The added expense wouldn't yield any better decisions about whether to wear a coat, so why bother? We are interested in tracking the relative costs of the various projects we undertake in our organization. We must admit up front that we will never be able to measure the precise cost of each of our projects. Consider the following things you could include in the "true cost" measurement of a project. Where will you draw the line? An engineer reads an article on the bus that give

Beyond Scrum?

[Adapted from a post to our internal Slack team.] My manager has been working to get an agile consultancy into our university's central IT department to help us progress in our journey toward being more agile. I hope that the training and coaching we receive will focus more on the root principles of value in agile processes rather than on a single process like Scrum. Are there any root agile principles that you think we need to be better at embracing? Here are some that come to mind for me. Develop functionality vertically instead of horizontally. You don't create the database layer all the way, and then the web services layer all the way, and finally--after 9 months--start to create the web user interface. Instead, you find a way to introduce a complete feature that touches all those technology layers so that you can get real feedback about the usage and value of the system or feature. Be willing to throw things away. If we're going to experiment, we have to be okay