Software Tools

Do one thing well, and work together.

A Simple Review

leave a comment »

Brad Appleton reviews misunderstandings, and records many references and good quotes, for simplicity in software design.

My del.icio.us tags kanso and zen aesthetic mark my favorite references on simplicity.

My favorites, of Brad's quotes:

Besides the noble art of getting things done, there is the noble art of leaving things undone. The wisdom of life consists in the elimination of nonessentials.
– Lin Yu Tang

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
– Antoine de Saint-Exupéry

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity.
– David Gelernter

A complex system that works is invariably found to have evolved from a simple system that worked.
– John Gall

Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.
– Edsger W. Dijkstra

Architect: Someone who knows the difference between that which could be done and that which should be done.
– Larry McVoy

Manifest plainness, Embrace simplicity, Reduce selfishness, Have few desires.
– Lao-Tzu, Tao Te Ching

Written by catena

8 June 2006 at 1206

Aspect Orientation in Makefile Production Rules – References

leave a comment »

Written by catena

30 May 2006 at 1248

Aspect Orientation in Makefile Production Rules – Conclusions

leave a comment »

Suitability of makefile production rules as an aspect-oriented language.

Usefulness of extending makefiles towards aspect orientation.

Written by catena

30 May 2006 at 1248

Aspect Orientation in Makefile Production Rules – Makefile Extension

leave a comment »

Enhancing makefile production rules toward aspect orientation with a preprocessor (eg, m4).

Written by catena

30 May 2006 at 1247

Aspect Orientation in Makefile Production Rules – Analysis

leave a comment »

How each aspect of aspect-orientation applies (or doesn't) to makefile production rules.

Written by catena

30 May 2006 at 1247

Aspect Orientation in Makefile Production Rules – Examples

leave a comment »

Adding code-generation (eg, pduconvert) support to a build system (eg, WUCE), with abstracted code samples.

Written by catena

30 May 2006 at 1246

Aspect Orientation in Makefile Production Rules – Introduction

leave a comment »

Makefile production rules. As an implementation of the Backus-Naur form.

Aspect orientation.

Written by catena

30 May 2006 at 1245

Aspect Orientation in Makefile Production Rules – Abstract

leave a comment »

Thesis.

Executive summary.

Written by catena

30 May 2006 at 1244

Slashdot reacts to WiMAX

leave a comment »

Market research of WiMAX by self-selected Slashdot posters.

Tariq Qureshi, general manager at Pakistan's Wateen Telecom, concluded his presentation, at WiMax World Europe event in Vienna, with a message for the vendor: "Please don't let me down."

Written by catena

28 May 2006 at 1423

Nine Debugging Rules

leave a comment »

Dave Agans enumerates nine rules in his short book, Debugging. As a reminder, the rest of this post lists headers from the rule chapters, formatted in one page for my cube wall.

Understand the system. Read the manual. Read everything, cover to cover. Know what's reasonable. Know the road map. Know your tools. Look it up.

Make it fail. Do it again. Start at the beginning. Stimulate the failure. Don't simulate the failure. What if it's intermittent?. What if I've tried everything and it's still intermittent?: a hard look at bad luck; lies, damn lies, and statistics; did you fix it, or did you get lucky?. "But that can't happen". Never throw away a debugging tool.

Quit thinking and look. See the failure. See the details. Now you see it, now you don't. Instrument the system: design instrumentation in; build instrumentation in later; don't be afraid to dive in; add instrumentation on; instrumentation in daily life. The Heisenberg Uncertainty Principle. Guess only to focus the search.

Divide and conquer. Narrow the search: in the ballpark; which side are you on?. Inject easy-to-spot patterns. Start with the bad. Fix the bugs you know about. Fix the noise first.

Change one thing at a time. Use a rifle, not a shotgun. Grab the brass bar with both hands [stop and look, examine and think, then act]. Change one test at a time. Compare with a good one. What did you change since the last time it worked?.

Keep an audit trail. Write down what you did, in what order, and what happened [easier if you're recording your steps anyway in idiom files]. The devil is in the details. Correlate. Audit trails for design are also good for testing. The shortest pencil is longer than the longest memory [and automation is faster].

Check the plug. Question your assumptions. Don't start at square three. Test the tool.

Get a fresh view. Ask for help: a breath of fresh insight; ask an expert; the voice of experience. Where to get help. Don't be proud. Report symptoms, not theories: you don't have to be sure.

If you didn't fix it, it ain't fixed. Check that it's really fixed. Check that it's really your fix that fixed it. It never just goes away by itself. Fix the cause. Fix the process.

Written by catena

15 May 2006 at 2350

Posted in debugging