Photo by flickr user smohundro used under a Creative Commons license.

“No [Lego] army can stop an idea whose time has come.”
–Victor Hugo

Visiting parents + a major work deadline = no posts this week.

Photo by flickr user brooksb used under a Creative Commons license.

Many years ago two salesmen were sent by a British shoe manufacturer to Africa to investigate and report back on market potential.

The first salesman reported back, “There is no potential here – nobody wears shoes.”

The second salesman reported back, “There is massive potential here – nobody wears shoes.”

As a Certified Scrum Master, I continually re-assess how to best apply Scrum principles to deliver software projects. One of my main criticisms of Scrum is that it is often misunderstood and sold as a panacea for bad software practices. It seems dev managers want to believe that Scrum will allow them to extract stellar results from poor and mediocre performers.

What a real Scrum looks like:

(Photo by flickr user boocal used under a Creative Commons license.)

In my experience, the only common ingredient to all successful projects is: strong software developers. Scrum (or any other software methodology) is no substitute for solid software fundamentals (such as strong object-oriented design skills).

Katie Lucas expresses this more eloquently. Her entire post is worth reading for anyone in the software profession.

Every methodology I’ve come across has, at its kernel, a very small section labelled “do magic here.”

[A software methodology is sometimes] pushed as a way of getting normal people to do something normal people can’t do. Normal people can’t do OO design properly. I don’t mean that derogatively as such. I can’t draw still life, I can’t run 100m races…People have various different talents. One of those talents is doing OO design and some people just can’t do it. No matter how much paperwork you surround it with.

And at the core of [a software methodology] is a small area where you have to use OO design talents…. if you don’t have them, it’s like having a methodology for running the 100m.

“Step 1: write about running really fast. Step 2: Go and draw a plan of the racetrack. Step 3: go and buy really tight lycra shorts. Step 4: run really, really, really fast. Step 5: cross line first”

It’s that step 4 that’s the tough one. But if you put lots of emphasis on 1,2,3 and 5 it’s possible no-one will notice and then you could probably make a lot of money selling the methodology to would-be
athletes who think there’s some “secret” to being a 100m runner over and above being born with the ability to run fast.

(Taking the cue from Charles Dickens’ weekly serials, I’ll share my thoughts on this topic over a series of posts, with one post each week. On June 16, I briefly touched on the motivation behind Kinetic. Now, let’s dig even deeper into the underlying motivations.)

The central premise behind Kinetic is: Useful diagrams must reflect increasingly-complex ideas and systems. Since Kinetic’s goal is to explore better approaches to diagramming complex systems, let’s first answer the question:

“Well, what’s wrong with the today’s tools to create complex diagrams? Why can’t we just use Microsoft Viso for diagramming complex systems?”

First let me be clear: I absolutely love Visio. In fact, as a Solutions Architect for Motricity (note: Kinetic is personally-funded and is not associated with Motricity in any way), I create and review hundreds of Visio diagrams each year. Anything from high-level technical architecture diagrams to low-level software component diagrams to business process flows. My good friend Sean C. (and the best database engineer I know) jokes that I’m utterly useless without Visio. And he’s right. Visit my desk on any workday, and chances are, you’ll probably see some Visio diagram on my monitor.

Diagramming software such as Microsoft Visio or Omnigraffle allow users to draw boxes, and then drag-and-drop arrows to link the boxes. For simpler diagrams, this intuitive approach works well.

But where tools such as Visio fall short is in dealing with complex diagrams. What do I mean? When diagramming systems that contain hundreds of interacting components, the Visio connector lines start to criss-cross in a spaghetti-like mess. Just for fun, here’s a particularly atrocious example:

Image from: http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx

Too many times, soon as the diagrammed systems or processes cross a certain threshold of complexity, the Visio diagrams become unwieldy and unmanageable.

In the next post (next Tuesday), I’ll share my thinking on the unwieldiness, and how Kinetic deals with it.

A couple of weeks ago, I accepted “Mission Capistrano” to automate the deployment process. I figure I owe an update: Well, it’s “Mission accomplished!”…all thanks to Capistrano.

(Photo by pasukaru76, Creative Commons license)

Meet Capistrano, my new unpaid and overworked robotic intern. Today, instead of dealing through multiple tedious steps, I simply type:

cap deploy

and Capistrano automatically takes care of the dirty work. What used to take 15 minutes now takes less than 4 seconds.

Here’s my 8-line configuration file…feel free to use it as a starting point for your projects:

set :application,  "kinetic"
set :repository,   "."
set :scm,          :none
set :deploy_via,   :copy
set :copy_exclude, [".DS_Store", "vendor"]
set :deploy_to,    "/home/kinetic/kineticdiagrams.com/"
set :user,         "kinetic"
role :app,         "kineticdiagrams.com"

With Capistrano, I can painlessly to deploy to multiple servers in parallel. And my favorite feature is that I can roll-back to any previously-deployed version. Let’s say I accidentally deploy a bug in my application code and expose my gaffe to the world. With Capistrano, I can easily roll-back to an earlier working version

cap deploy:rollback

and continue with the rest of my day, dignity intact. If only my romantic relationships had a similar “undo” button…

Photo by flickr user edmittance used under a Creative Commons license.

“Space I can recover. Time, never!”
–Napolean Bonaparte

Dealing with personal issues tonight, no Kinetic update.

In a historical romance Sun Tzu is represented as saying to Wu Yuan: “As a general rule, those who are waging war should get rid of all domestic troubles before proceeding to attack the external foe.”
–Sun Tzu, The Art of War (“The Art of Maneuvering”), 1933 translation

Graphviz now successfully works on my Snow Leopard installation.

The root cause: Turns out that some of my earlier MacPorts ports were outdated since they were built when I was still running Mac OS X Leopard. Installing the graphviz-gui port would appear to be fine, however, since some of the Graphviz dependencies were outdated for Mac OS X Snow Leopard’s 64-bit architecture, running the graphviz-gui port would fail.

The fix: By re-installing the graphviz-gui port after wiping out all the installed MacPorts ports (and therefore starting from a “clean” starting point), all of the Graphviz dependencies were re-installed correctly to work with Snow Leopard’s 64-bit architecture.

Command-line history:

sudo port -f uninstall installed
sudo port install graphviz-gui
dot -Tpng /tmp/diagram.txt > /tmp/test.png

Running into issues getting Graphviz to play nicely with Snow Leopard. This post describes my very issue; unfortunately, the only potential “fix” it describes is to re-install MacPorts from scratch. Frustrating.

Ed B. shared an interesting idea today. Ed suggests that I consider linking this WordPress blog to my Facebook account. That way, all my Facebook friends will be able to effortlessly keep up with any new blog postings.

To be honest, that will require me stepping outside of my personal comfort zone, as I don’t usually publicize my projects. I tend to prefer working in solitude and seek perfection, before showing the fruits of my labor to others. So far, I’ve only shared the link to this blog site to a few friends at work. I admit that the idea of my Facebook friends being able to see my geekier side makes me a bit nervous.

Photo by flickr user smlions12 used under a Creative Commons license.

As it turns out, Kinetic is more than just a software experiment…it is turning into an experiment in personal growth, as well.

“‘Security’ is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. In the long run, avoiding danger is no safer than outright exposure. Life is either a daring adventure, or nothing.”
–Helen Keller, 1950:

“The perfect (summer) is the enemy of the good.”
–Voltaire (quote slightly adapted )

Too much to do, and loving every minute of it!

“Life is what happens to you while you’re busy making other plans.” –John Lennon

Stumbled onto this poem last week…I love it!

It Couldn’t be Done
by Edgar Guest

Somebody said that it couldn’t be done,
But, he with a chuckle replied
That “maybe it couldn’t” but he would be one
Who wouldn’t say so till he’d tried.

So he buckled right in with the trace of a grin
On his face. If he worried he hid it.
He started to sing as he tackled the thing
That couldn’t be done, as he did it.

Somebody scoffed: “Oh, you’ll never do that;
At least no one we know has done it”;
But he took off his coat and he took off his hat,
And the first thing we knew he’d begun it.

With a lift of his chin and a bit of a grin,
Without any doubting or quiddit,
He started to sing as he tackled the thing
That couldn’t be done, and he did it.

There are thousands to tell you it cannot be done,
There are thousands to prophesy failure;
There are thousands to point out to you, one by one,
The dangers that wait to assail you.

But just buckle right in with a bit of a grin,
Just take off your coat and go to it;
Just start to sing as you tackle the thing
That cannot be done, and you’ll do it

Old Mission Capistrano: Any child can prove: Every year, around March 19th, the famous swallows (the pride of Capistrano) return to deploy their mud nests in the ruins of this historical mission.

Photo by sp8254, Creative Commons license.

New Mission Capistrano: This year, by July 12th, my historic mission is to swallow my pride, and nest in my famously-muddy ruins, until my Capistrano deployments are child-proof.

My web app deployment process currently looks like this:

1. Fire up my FTP client.
2. Fire up my SSH client.
3. Type username, password, and server name, to login to my web hosting provider’s FTP server.
4. Type username, password, and server name, to login to the web hosting provider’s SSH server.
5. Navigate to the web directory where the web app is hosted.
6. Open up the folder on my MacBook Pro, where the web app files are located.
7. Carefully copy over each Ruby file to the corresponding directory on the FTP site.
8. Carefully copy over all supporting assets (images, stylesheets) to the corresponding directories on the FTP site.
9. Navigate (via typing) to the directory containing the server restart script.
10. Run the server restart script.
11. Validate that the updated version of the web app has indeed been deployed, by firing up a web browser to the web app’s location.
12. If something is amiss, then revisit steps #5-#10 as necessary.
13. Close the FTP client.
14. Close the SSH client.

Photo by flickr user tzofia used under a Creative Commons license.

By next Monday, I’d like it to look like this:

1. Run a single script.

The sooner I can streamline this error-prone process, the sooner I can re-focus on fun.

Tonight, I re-connect with Chris, an old Harvey Mudd College friend, and we start talking about our personal projects. Chris shares my passion for building, and he’s currently working on a fitness class locator application. Several good reminders came up in our conversation:

1. The actual technologies used to build our apps usually matter less than we think.
2. Focus on end-user value.
3. It’s near impossible to stay up to date with all the latest technologies, so don’t even bother. See points #1 and #2.
4. When working on a project as the solo contributor, make sure you have someone to bounce ideas off of.
5. Old systems are built that way for a reason. Learn the intricacies of the existing system before you start to re-engineer a new replacement solution.
6. Remember to enjoy the other aspects of life while working on projects.

…enjoying the creative process