The Interface. The Chicken or the Egg?
In my previous weblog entry, I disagreed with the advice in Getting Real about getting to “Done!” as soon as possible. In this entry, I will disagree with another piece of advice, which is that you should design the application’s interface before you start programming. Hogwash!
Every software application is created to solve a problem. Even a game is created to solve the problem of, “I’m bored.” Surely it stands to reason that if a software application is created to solve a problem, then the first thing you should do is solve the bleeding problem! You could design the sexiest interface in the world, but if it is not attached to software that solves the problem, then the software will fail. You could design the fastest database in the world, normalised to the tenth normal form, but if it is not attached to software that solves the problem, then the software will fail.
This is a common complaint about games released in the last few years. They look great, run fast, but are simply boring to play. The actual problem of, “I’m bored, entertain me,” has not been solved. In contrast, check out Boom Boom Volleyball. This game looks poor, runs slow, but is fun to play. Since it solves the stated problem, is it not successful?
Another problem with the interface first approach is that it will lead to shortcuts. The idea put forth in Getting Real is that you create the interface, first on paper and then in HTML, and then turn that static HTML into a dynamic application. This is the approach that leads to developers creating .aspx pages that grab data directly from the database, loop through that data, and spit it out onto the page. Sure, it works, but it is a shortcut between the data and the interface. What is missing is the business layer—the layer where the problem is solved.
A further problem with the interface first approach is that it leads to software that grows by addition, not by multiplication. (For the more mathetically inclined, the growth is linear, not exponential.) To add a new feature means to create a new static interface element, and then add all the code necessary to turn that static element into a dynamic element. To add another feature means to do the same thing again. What is missing is any chance for emergence to occur and to grow the software. If the developer spends time solving the problem in the business layer, and adds the infrastructure to support that solution, then other features can grow naturally from that base. Each time you expand that base and make it richer, the less effort needed to implement the next feature.
The second argument put forth by the authors of Getting Real for designing the interface first is that “the interface is your product.” Again, that’s hogwash. Nobody buys a software interface. Customers buy a solution to a problem. The interface has a huge part to play in whether the product delivers the solution, but it is the solution a customer buys, not the interface.
As an aside, I’ve never understood how “Which came first, the chicken or the egg?” qualifies as challenge. The egg came first. Unless evolution can occur within a single animal’s life—but it cannot—then the egg must have come first. Think about it.
by Alister Jones | Next up: Should the Ghost in the Machine be Invisible? →
----
Post a Comment