EppsNet Archive: Software Design

Amateur Design

3 Aug 2013 /

The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate “functions and features” to the developers, carefully disguised as “customer requirements.” Maybe conveyed by our Product Owners. If you go slightly below the surface, of these false “requirements” (“means,” not “ends”), you will immediately find that they are not really requirements. They are really bad amateur design, for the “real” requirements — implied but not well defined.


Every New Feature is a New Failure Point

14 Apr 2013 /

The TPMS warning light on my car dashboard is lit up, which, according to the owner’s manual, indicates a malfunction in the Tire Pressure Monitoring System, a system designed to alert me, via a different warning light, when the tire pressure gets too low.

It’s a completely unnecessary system to begin with because I can monitor the tire pressure myself, as drivers have done since the invention of the automobile.

Let’s add a completely unnecessary new system so when it breaks, the owner will have to pay to fix it.

Can I just ignore the warning light? I don’t know. The worst-case scenario is that the TPMS not only breaks but creates a domino effect that knocks out a critical system that I actually need.

Toilers in software development can draw their own analogies . . .

Thus spoke The Programmer.


Rough Layouts Sell the Idea Better Than Polished Ones

29 Nov 2012 /

This was written by an ad man but I can see it applying to other endeavors, like designing a software interface:

Scribbling

If you show a client a highly polished computer layout, he will probably reject it.

There is either too much to worry about or not enough to worry about. They are equally bad.

It is a fait accompli.

There is nothing for him to do. It’s not his work, it’s your work. He doesn’t feel involved.

If he doesn’t like the face of the girl in your rendering, or the style of the trousers on the man on the right, or the choice of the car he’s driving, he’s going to reject it.

He won’t see the big idea. He will look at the girl’s face and think, ‘I don’t like her, this doesn’t feel right.’

It is very difficult for him to imagine anything else if what you show him has such detail.

Show the client a scribble.

Explain it to him, talk him through it, let him use his imagination.

Get him involved.

Because you haven’t shown the exact way it’s going to be, there’s scope to interpret it and develop and change it as you progress.

Work with him rather than confronting him with your idea.


Kanban, Scrum, User Stories, System Design

24 Apr 2011 /

Customer Engagement

24 Oct 2010 /
Book cover

You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it.

— James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development

Convergence

8 Jun 2010 /
8mm Fisheye Test

The distinctive conduct that marks successful project teams is this: They know there is a time to diverge and a time to converge. That is, in each of the project planning phases (e. g., feasibility, conceptual, definition, execution), the team first moves outward (diverge) to gather information and ideas and to generate alternatives — only then does the team move inward (converge) to focus, evaluate, and select.


Visualize the Properties

27 Feb 2010 /
Jim McCarthy

Imagine and identify the few properties of your product or service that will gratify the customer’s need. Visualize the properties, desire them yourself, and everywhere ensure and intensify their presence.


Evolving a System

1 Feb 2010 /
Simplicity

A complex system that works is invariably found to have evolved from a simple system that works . . . A complex system designed from scratch never works and cannot be patched up to make it work.

— John Gall

Software Tips from Bjarne Stroustrup

23 Nov 2008 /

Here are 38 tips from the designer of the C++ programming language.

These in particular jumped out at me:

[5] Don’t try technological fixes for sociological problems
[8] Design processes to encourage feedback
[9] Don’t confuse activity for progress
[10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested
[19] Use existing systems as models, as inspiration, and as starting points
[22] Design for change, focusing on flexibility, extensibility, portability, and reuse
[27] Keep it small. Don’t add features “just in case”
[29] Repeatedly review and refine both the design and the implementation
[31] Experiment, analyse, and test as early as possible and as often as possible


You Have to Explain Something to a Computer

9 Aug 2008 /

When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.”

It’s so hard to do the design unless you’re faced with the low-level aspects of it, explaining it to a machine instead of to another person.

— Donald Knuth, Communications of the ACM 58, 8 (Aug. 2008)

Best and Worst Software Features of the Week

24 Feb 2008 /

I was typing in Microsoft Word and I started a bulleted list with an item like this:

  • Topic1. A sentence about Topic1. And another one.

Then I hit the Enter key.

What do you think happened?

Not only did I get another bulleted list item, Word set the font to bold!

So I typed this:

  • Topic2.

And as soon as I typed the period, Word turned bold off!! Not only did it figure out that I’m creating a bulleted list, it figured out that I’m starting each bullet with bold font, followed by a period, followed by more text in regular font, and it takes care of everything for me automatically! That’s pretty sophisticated.

Compare that to Lotus Notes, which can’t even figure out when I hit Enter twice that I want to turn the bullets off!

We use Notes at work and I swear to God, if I type a bulleted list and hit Enter twice, Notes gives me this:

  • Item 1
  • Item 2
  • Item 3
  •  
  •  

I actually have to turn bulleting off manually! Does anyone really want to create a bulleted list with multiple empty items?

I’ve never seen another text editor do something this stupid . . .


Lotus Notes Sucks

23 Feb 2008 /

I’m working with a company that uses Lotus Notes. It’s been more than 10 years since I’ve had to use Notes and it’s as bad as ever. It’s probably the worst piece of software ever released by a major company.

The worst feature — well, it’s hard to pick a worst feature, but one of the worst features — because I have to deal with it dozens of times a day — is the way Notes makes me reply to email. I can’t just click Reply and start typing. When I click Reply, I get a dropdown list of options and have to select one:

– Reply
– Reply with History
– Reply without Attachment(s)
– Reply with Internet-Style History

The godawful thing about this is that default options for email work 100 percent of the time. I always want to reply with history and without attachments, so why give me a bunch of options that I don’t want and make me explicitly select one every time?

Why would I not want to reply with history? If I’m sending replies without including the original email for context, most people send and get way too much email to remember what the heck I’m responding to.

And why would I send an attachment back to someone with my reply? They already have the document. They sent it to me. They don’t need another copy of it. But every day I see emails going back and forth across the network with multi-megabyte attachments because people have to explicitly select an option to remove it.


Respect the Classics, Man: No Silver Bullet

28 Jun 2006 /

This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach.

Continue reading Respect the Classics, Man: No Silver Bullet


Requirements are Boring

6 Aug 2005 /

You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . .

Who has built something that their customer will certify is part of what they want? That’s interesting.

Who has shipped something to their customer and the customer is using it? That’s very interesting.


A Couple of Quotes on Software Design

14 Oct 2002 /

I conclude that there are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

 

A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later.

— C. A. R. Hoare, Turing Award Lecture, 1980