Tag Archives: softwaredev

What!!??

Ever heard the phrase “I want to hear about solutions, not problems”?  Executives, managers, consumers of services, and users of software use the phrase when all they want is for a problem to get solved, among other reasons. Software developers should only use it when filling one of those roles, even though you should avoid it to prevent an unsolvable problem from rising to the surface. Software developers provide the solutions to problems. They should approach their interactions with users, and sometimes our peers, as “I want to hear about problems, not solutions.”

Several times in my career, business owners and technical peers approached me to present several solutions for unclear problems. I’m guilty. I present my share of solutions without clearly stating the problems they intended to solve. In many cases, the solution presented did not solve the problem the presenter intended to solve. In others, the presenter’s authority or tone gave no option to developers for inquiring about the problem in order to find another, perhaps better, solution.

As a software developer myself, I want to hear about problems, not solutions. Every feature request, bug, improvement, etc. presents a problem someone needs to solve.

I’m not suggesting anyone use this statement as a challenge. The “solutions, not problems” phrase is typically used to eliminate excuses. Software developers should professionally inquire about the problems a presented solution intends to solve. We owe it to our users, managers and executives to do this… it’s what we, as software developers, are paid for.

Focus on problems before identifying a solution. When you start to identify a solution, think and/or find out about other similar problems that might exist. Evaluate those against your solution. When you’re done, restate your problems when you present your solution.

P.S.

I wrote the article above on an internal blog at my old my old place of business minus some minor editorial adjustments. At the end of last month, Coding Horror included a couple of posts on a similar subject. The first said the following that triggered me to thinking about this post again.

Users often don’t know what they want, and even if they did, the communication is likely to get garbled somewhere between them and you.

How do you achieve modern web site design today? I know several designers who swear the answer is divs in the html, not tables.

In one case at my last job, the designer insisted on divs. Unfortunately, he insisted too much without effectively describing the benefits of using divs instead of tables. He alienated some important people. It just so happened it was just as easy to achieve the desired effect with tables, just not as flexible if someone wanted the layout changed. At the time the debate was raging, I agreed with the important people about just getting things done with the tables. I sat down to discuss with the designer and listened his explanation of the benefits. The debate was resolved by changing the parties involved in the design.

I still believe tables are the best way to get the job done when you are sure you are sticking with a certain web page layout. It’s quicker to put together the html for the table and have the layout looking the way you want it like this:

Table Based Layout Example

Here’s the code:

<html>
<head><title>Table Layout Example</title></head>
<body>
<table>
  <tr>
    <td colspan=2 style="text-align:center;background-color:grey;border: 2px solid;">
      <h1>Header</h1>
    </td>
  </tr>
  <tr>
    <td style="height: 200px;width:20%;background-color:grey;border: 2px solid;">Left column</td>
    <td style="width:70%;text-align:center;border: 2px solid;"><h2>Content Area</h2></td>
  </tr>
  <tr>
    <td colspan=2 style="text-align:center;background-color:grey;border: 2px solid;">
      <h3>Footer</h3>
    </td>
  </tr>
</table>
</body>
</html>

What if your web page has to support branding? Now you have a customer who requests the left column show up on the right? Now you’re stuck, especially if that table is generated by code. You have to say, “we only support designs that fit in our box.”

If that layout were built with divs, you would be better positioned to meet the customers request.

Take this basic layout that pretty closely matches the table-based layout example above:

Div Based Layout Example - Default Layout

The HTML:

<html>
<head>
  <title>Div Layout Example - Default Layout</title>
  <link rel="stylesheet" type="text/css"  href="default.css" media="screen"/>
</head>
<body>
  <div id="container">
    <div id="header">
      <h1>Header</h1>
    </div>
    <div id="leftcol">
      Left column
    </div>
    <div id="content">
      <h2>Content Area</h2>
    </div>
    <div id="footer">
      <h3>Footer</h3>
    </div>
  </div>
</body>
</html>

With one modification to the stylesheet href in the HTML, which could be driven by a customer configuration setting:

<html>
<head>
  <title>Div Example - Option 1 Layout</title>
  <link rel="stylesheet" type="text/css"  href="option1.css" media="screen"/>
</head>
<body>
  <div id="container">
    <div id="header">
      <h1>Header</h1>
    </div>
    <div id="leftcol">
      Left column
    </div>
    <div id="content">
      <h2>Content Area</h2>
    </div>
    <div id="footer">
      <h3>Footer</h3>
    </div>
  </div>
</body>
</html>

(OK, I changed the title, too.)

I get this layout:

Div Based Layout Example - Optional Layout

That’s all there is to it… well, sorta. That would be the only change to the code that generates the html. A designer, which I am admittedly not, would have to put together the stylesheets.

The default.css stylesheet used in the first example:

#header {
  background-color: grey;
  width: 356px;
  border: 2px solid;
  margin-bottom: 2px;
  text-align: center;
}
#footer {
  background: grey;
  width: 356px;
  border: 2px solid;
  margin-top: 208px;
  text-align: center;
}
#leftcol {
  background: grey;
  float: left;
  width: 100px;
  height: 200px;
  border: 2px solid;
}
#content {
  background: white;
  float: right;
  width: 250px;
  height: 200px;
  border: 2px solid;
  text-align: center;
}
#container {
  width: 360px;
}

The option1.css used in the second example:

#header {
  background-color: grey;
  width: 356px;
  border: 2px solid;
  margin-bottom: 2px;
  text-align: center;
}
#footer {
  background: grey;
  width: 356px;
  border: 2px solid;
  margin-top: 208px;
  text-align: center;
}
#leftcol {
  background: grey;
  float: right;
  width: 100px;
  height: 200px;
  border: 2px solid;
}
#content {
  background: white;
  float: left;
  width: 250px;
  height: 200px;
  border: 2px solid;
  text-align: center;
}
#container {
  width: 360px;
}

So, even though I agreed we should be just getting the job done with tables at the time my designer colleague was insisting on divs, I see the benefit in the div-based layout. It’s more flexible when supporting morphing design requirements or supporting multiple layouts with common code.

Over the past couple of weeks, we were discussing design needs of our customers with respect to a product of a third-party my company partnered with to sell. The design was based on a table layout and the customer was left wanting more. We pitched converting the table-based layout to a div-based layout with the argument that it was more flexible, and ultimately more successful. I think they’ll be moving forward with the recommendation.

We need to update the design our various web portals in my current job. I plan to use the div based design layout to allow for maximum flexibility in meeting our customers desires. However, it was more difficult, at least for me, to put together the first div example and related stylesheet. The second layout was much easier and that may hold true with number 3 through n.