Easy and Simple Isn’t

I’ve been building up content (for here and for eventual videos) regarding reducing the pain of software development.

In particular, I’ve become fascinated with two challenges:

  1. Writing the right software
  2. Writing the software right

Imagine a team of perfect developers. They can take any user story, use-case, requirement, specification (or whatever term a given methodology uses) and generate 100% flawless and efficient code. They never have bugs, they never run low on memory, and they never have unexpected effects no matter how convoluted or wrong the input provided is.

You task them to write something, knowing it will be, in a word — perfect. And the first time the intended audience uses it they reject it as totally broken. How can this be?

In fact, this is the normal case — what they wrote was written “right” but it wasn’t the solution to the right problem. In short: they misunderstood the requirement. Perhaps they simply made a mistake, or perhaps the requirement was incomplete, inconsistent, or even totally wrong. But from that requirement, they built an executable program.

This is the worst case scenario for any software effort. Bugs can be fixed, but if the wrong problem is addressed, then it may be that nothing is salvageable from the code.

It seems obvious, and I can write about it as above, but what’s not obvious is the culprit of this painful problem: we can’t test a requirement. We can “validate” it, we can “review” it, we can “think about it.” But we can’t invoke it against data and see if it works. The requirement is generally some form of text and diagrams. It’s not code. And how could it be? Coders write code and the requirement comes first!

I have the worlds “dumbest” user story (and problem) as the example I’ve been working with. I actually use this example (precisely because everyone “knows” how the user story works) as a way to evaluate tools when I need to test logic. The user story is this:

Simulate a bedside lamp that responds to three events: plug in the power cord, remove the power cord, use the switch to cycle the light on or off.

Think about that use case for a moment. Then ask what should happen in the following sequence of events:

  1. plug in the lamp
  2. use the switch (the light turns on)
  3. unplug the lamp (the light turns off)
  4. plug in the lamp

Will the light come on when the lamp is plugged in?

The proper answer to that question is “It depends on the kind of switch — electronic or mechanical switch.” Mechanical lamps have their switch independent of their power. Electronic lamps have their switch work only when energized (under power). As a result, when you depower an electronic lamp, when you plug it back in the switch reverts to its default and the light is off. This is also the standard behavior of a “modern” TV or monitor, where the power button only works when the device is plugged in.

However, I can’t just claim that, so I bought two lamps from Target, one with a touch-switch and one with a normal knob. That way, I could film the effect. In other words: I sought to test my example and prove the real world case before simulating what I “knew” to be the truth.

And the touch-switch lamp did NOT follow the rules — any of the rules.

To my surprise, I discovered that when I plugged it in, powered it up, unplugged it, and plugged it back the light came on — but at a different intensity. Further testing (frantically plugging/unplugging and poking with finger and screwdriver) showed that the lamp utterly disobeyed all my expectations.

So my simple example to show that a basic textual use-case “simulate a bedside lamp” was in fact far more difficult than I even expected. And yet, I’ve actually given this example to people and had them say the code would be easy.

Easy, perhaps — but if they didn’t ask “What kind of lamp?” and now, I’ve learned, “What make and model of lamp?” they would have written the wrong code.

They’d have solved the wrong problem. Their code would have worked only to simulate some lamps but not this beast I now have sitting on my desk.

I still need to buy another lamp (a third lamp) that does what I expect. But my trivial example has become far less trivial.

And to think — we’re expecting professional development teams to build software on prose descriptions of problems far more complex than a bedside lamp.

Keep the Light,
Otter
Brian Jones

3 thoughts on “Easy and Simple Isn’t

  1. Pingback: Executable Requirements Concept | Limitless Knowledge Association

  2. Pingback: Are Proofs of Concept Tools? | Limitless Knowledge Association

  3. Pingback: Worked Executable Requirement Example | Limitless Knowledge Association

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s