Don’t Work on the Wrong Machine

Posted on August 28th, 2008 by Chris.
Categories: Business/The Software Industry, Chris, Programming.

Fred Brooks: Build one to throw away

My version: Build every one to throw away.

Fred Brooks’ classic The Mythical Man-Month made this observation developing a new piece of software - inevitably, many of the problems that will need to be solved won’t be known until you try to solve them. The first try will incorporate many feelings of should-have and would-have that will be fixed on the second try.

Carter made a bench!

This is much like a journeyman craftsman building his or her first bench, or planting their first garden. The first try is a learning experience. There is no way around this, nor should there be - learning is often best by doing. The valuable asset is the experience of the builder, not the product.

But we don’t live in the Middle Ages, the age of guilds. We live in the post-Industrial Age. Factory owners don’t consider hoarding all the toys or cars or electronics they produce as an asset. Henry Ford’s genius was to redesign not just the golden eggs, but the machine that lays them.

As programmers, we are not working on a code base. We are working on a machine that produces code. The machine is made up of us, our experiences, the tools we build to make code (which can be made out of code themselves!). This is where results come from, and we should spend our time tuning this machine by producing more, not protecting what we have.

Does this mean that we should throw out old code? By no means! Old code is one of the most efficient resources we have for producing new code. But every process of manufacture in the past has been made into a more automatic and refined process. How could we consider ourselves any different?

Does this mean that we should code like crap? By no means! As was once said, “If you write the first one to throw out, you will end up throwing out the second one as well.” The point is, write good code, but be willing to write new code - the point is to make not good code, but a good code factory.

0 comments.

Mulberry: Tribute to the Greatest E-mail Program of All Time

Posted on May 21st, 2008 by Chris.
Categories: Chris, General/Misc., Product Design, Programming, UI Design.

For years I have used and loved Mulberry, perhaps the best e-mail client in existence. So I was greatly saddened to hear that Cyrusoft, the company behind Mulberry, declared bankruptcy a year ago.

[more (full article)]

I was just as much shocked as dismayed. Mulberry was hawked by so many colleges that I assumed its destiny was all but sealed. College students, as early adopters, would all be exposed to Mulberry and see how wonderful it was, and they’d take it to their jobs, promoting an almost viral spread.

I guess the Thunderbird/Outlook duopoly was just too strong for Cyrusoft to handle. However, all is not lost, as Mulberry is available for free now.

Let’s take a look at all the wonderful features of this program! (full article)

[originally started a long time ago]

0 comments.

Security in UI

Posted on March 15th, 2008 by Chris.
Categories: Chris, General/Misc., Product Design, Programming, UI Design.

One of the most common ways to secure a computer is by using a username/password combination. (In fact, we don’t have to look far to find an example). However, this system is clunky, primarily because it requires you to remember or write down the user name and password for every site (or alternatively use the same password everywhere).

Security is not just about locking down a system from a list of attacks. The way you design a UI dictates how people behave, and people’s behavior is responsible for 90% of attacks. [citation needed] Defaults matter. No one forgets to lock an automatically locking door.

The fact is, while a security system must be set up to prevent hacking attacks, guesswork, and theft, it must also be designed in such a way that leads people to behave more securely. When you have a system where keys are hard to create but easy to copy, naturally, people will end up using the same keys at eBay that they do at Flickr.

The need to “educate users” is an indication of design failure.

2 comments.

~One Paragraph Blog: How scary is the rewrite?

Posted on February 18th, 2008 by Chris.
Categories: Chris, Programming.

Do you work in software engineering? Have you ever heard a coworker say, “I’d do X, but then I’d have to rewrite everything?” Truth is, it’s easier to rewrite everything than make small changes sometimes.

How could I justify something so outlandish? Simple. The difficulty of a change (how many hiccups, how many bugs) depends not so much on its scope as it does on how well planned it is. Inevitably, we underestimate how much planning small changes take, and overestimate when we see big, scary changes. Does this mean rewrite is easy? Of course not. But it’s not impossible, or as costly as we think, and just the opposite is true for minor changes.

*The usual caveats: If you have a problem that can be solved with a small change, I recommend sticking to that before resorting to bigger changes. But once you start seeing so-called small changes multiply, you may have hit the stall point.

1 comment.

Older »