Category: Softwares

It will never look like that. It is all too easy to fall into the trap of investing large amounts of time in a design and being confident that the implementation will come out the same. A detailed design can easily fool you into believing you have every angle covered. The greater the detail and the more in-depth the research the greater your confidence in it. But it is an illusion: it will never look like that.

The truth is no matter how in-depth, how well researched and how well thought out your design it will never come out looking the same as in your head. Something will happen, an external factor may effect the design: incorrect information, a limitation, an odd behaviour in someone else’s code. Or you may have got something wrong: an oversight, an incorrect presumption, a subtle concept missed. Or something will change; the requirements, the technology, or someone may just find a better way(TM).

Those minor alterations in the design soon stack up and lots of minor alterations soon require that one big one has to be made. Before long your original concept is on the floor in pieces and its back to the drawing board. You decide what you needed was more design, more detail, so back you go and the next architectural vision is clearer, more radical, more perfect than the last. But before long the same thing happens, those changes start to appear and shift your design and developers keep shoving in more and more stuff trying their best to work around the broken design but just breaking it more and you end up screaming “of course it’s got bugs; it was never designed to do that!”.

Design is a discovery process, as we implement we discover new information, often impossible to know up front. By accepting that design is an ongoing and empirical process in a forever changing world, we learn that the design process must be flexible and ongoing too. Clinging onto your original designs and trying to force them through is only going to end up with one result so you need to learn to understand that it will never look like that.

As you work in requirements meetings to design software, pretend that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true.

Your customer is not your customer. Your customer‘s customer is your customer. If your customer’s customer wins, your customer wins. Which means you win.

If you’re writing an ecommerce application, take care of the things that you know people who will shop at that site will need. They’ll need transport security. They’ll need encryption of stored data. Your customer may not mention these requirements. If you know that your customer is leaving out things your customer’s customer will need, address them, and communicate why.

If your customer willingly and knowingly doesn’t care about certain important things that your customer’s customer cares about—as happens from time to time—consider stepping away from the project. Just because Sally Customer doesn’t want to pay for SSL every year and wants to store credit cards in plain text because it costs less to build, it’s not okay to just agree. You’re killing your customer’s customer when you agree to work you know is a bad idea.

Requirements gathering meetings are not implementation meetings. Forbid the customer‘s use of implementation-specific terms unless it’s an absolute, or well-understood problem. Allow your customer to express only the Platonic ideal, his concept and goals, rather than dictating a solution or even using technical terms.

So how do you maintain such discipline in these meetings, which can be deceptively difficult? Remember to care for your customer‘s customer. Remember that while your customer is writing your check, you must be clear that you need to honor best practices, so that you can make what the customer really needs, not just what they say they need. Of course, this takes lots of discussion, and clarity as to exactly what you‘re doing and why.

Perhaps, as with so many things in life, this is best clarified by a poem. In 1649, Richard Lovelace wrote “To Lucasta, on Going to the Wars”. It ends with the line: “I could not love thee, dear, so much, / Loved I not honor more.”

We cannot love our customers so much, love we not their customers more.