Visualize the Properties

27 Feb 2010 / PE
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 / PE
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 / PE

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 / PE

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 / PE

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 / PE

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 / PE

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 / The Programmer

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 / The Programmer

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