August 2009 Archives

I’ve got a hankering to try my hand at GUI application development with Python. What’s a good framework to use? Which ones stink on ice?

My highest priorities are:

  1. Good on Windows.
  2. Ultra-easy for people to install the finished application.
  3. Won’t piss me off.

Any suggestions?

Minimal Site Designs

| Comments

subtraction.jpg

As you can tell from the elaborate imagery on Code Softly, I’m kind of a fan of minimal site designs. Design Shack posted 35 great ones.

My favorites are Subtraction (pictured above), Cynosura, and Tobias Bjerrome Ahlin.

I’d like to think someday I could whip up a cool and clean layout for Code Softly that impresses people with my restraint and eye for clean lines. In the meantime, we’re all stuck with the design mess you see before you.

ideas.jpg

If your project has more “idea people” than builders, you’re likely having a rough time of things.

Think about it. A good idea almost certainly takes less time that its implementaton. If your project has more people thinking up features than implementing them, the implementors will never catch up.

Frustration prevails. The stage is set for disappointment. You’re always behind.

So what’s a good ratio of “doers” to “thinkers”? I submit it’s ten to one. It sounds drastic, but building software is complex stuff. If you pick one really good person to design feautres, and have ten working to implement them, you have a good chance at success.

The ten to one ratio also sounds horribly inefficient, but what’s the success rate of new ideas when you’re spouting out all kinds of new features? Does more than one in ten of your features really ever pan(pay) out?

Construction projects are a nice example. The ratio of builders to architects on a typical high rise is like 50 to 1.

We wouldn’t dream of having 50 or 75 architects for a building, so why are we ok with the same percentage for software?

[photo courtesy of joherob - some rights reserved]

Commit EVERYTHING

| Comments

To the mantra of Commit Early. Commit Often, I humbly submit Commit EVERYTHING.

When I was a wee young programmer and had my first experience with cvs, I was scared. Optimistic locking was mysterious. I only wanted to check in one teeny change at a time.

Eventually, I got comfortable and realized that committing my ENTIRE working copy is the only way to be sure I haven’t broken things.

Sins against this range from

“Shoot, I forgot to svn add that file before committing, sorry guys; One sec..”

to

“Well, I was keeping my own version for the last few weeks until I felt like it was really done.”

In the end, not committing your entire copy keeps you out of touch with the codebase and threatens stability. You leave yourself wide open to “Well, it works for ME”, when really you just have local changes you haven’t committed yet.

There’s a few ways to have your cake and still eat it. If you feel the urge to not commit everything, you might want to:

  1. Make your own experimental branch and work from that for a while (remember to merge in changes from trunk occasionally/)
  2. Commit more often, and in smaller chunks.
  3. Write enough tests so you can verify the integrity of the entire working copy before committing.

Too much pain and time is wasted when you need to decide which files are safe to check in, and which ones aren’t quite done yet.