The Ukelele and the Guitar

I'm going to talk about Software Engineering for a moment. You may have heard that ObamaCare's website has missed all its deadlines, and is a perilous application to entrust your sensitive personal information. And folks like Bruce Webster can give you chapter and verse as to why.

I just want to show a simple illustrative example.

Consider this musical instrument:

It is a ukelele. It has 4 strings, it has frets, tuning knobs and that wooden box with a hole in the middle. Suppose I were to tell you that I wanted to upgrade this instrument by "just" making it longer, and adding two strings. I'd be asking you for this instrument:

You will recognize this instrument is a guitar.

I had a conversation much closer to home yesterday. Months back someone I know bid on building a system that consisted of database, data collection application, and an analysis module. It was for a lot of money and to save money the buyer opted instead for just the database.

Also, the buyer decided to bring the data collection application in-house.

Trouble was that the buyer's staff proved unable to do it in-house. So they went back to my friend to build them something to show what the data collection application would look like. And as you can probably expect, the buyer is now complaining about the limited functionality of the demo.

"Can't you just build up the demo into a working system?" The answer is yes, but it is also more expensive.

Consider the problem of upgrading a ukelele to a guitar. The stresses on the body are a a LOT greater in the guitar, because you've got half-again more strings, and you've got a much longer span over which those strings must be tensioned. You can't just bolt on two more tuning knobs and patch the neck of the thing to make it longer, and wider. All the strings have to be replaced, because all the old ones are too short. And the box can't just be patched, it has to be replaced.

That's what my friend and his client's software has to deal with. Sure, it looks like all you have to do is fix a few defects, but the problem is deeper. There are software equivalents of loads and stresses that have to be engineered. Little hacks that might look right in a demo to a bunch of managers can't bear an operational load.

One of the central problems of software development is visibility. You can't see what's wrong unless you know what to look for. And the warning signs are easy to ignore.

So, next time you see a pre-launch demo that looks OK, ask yourself, "Is this a ukelele or is it a guitar?" And if you need a ukelele, expect to pay the full price of a new guitar.

In Praise of Bar Camp

I hear that years back Tim O'Reilly or some other rich guy out west started having these rather exclusive get-togethers for only the best people. This is cool. It's his right to spend his time and money as he wants. This get-together was called Foo Camp.

When you draw a circle around the best people--or any circle for that matter--there's going to be a lot more people outside the circle than inside. And some of those people on the outside thought it would be a good idea to have a non-exclusive get-together for all the average Joes like me. And they organized something with the name Bar Camp.

Over time, the phenomenon of Bar Camp made its way to Grand Rapids, MI and five years ago I went to my first Bar Camp. I'm wearing a tee-shirt that Google gave away that year. In subsequent years Google quit sponsoring Bar Camp and other local sponsors have chipped in. The food is better and it's all free.

The way Bar Camp works is that smart people get together and are confronted with a blank piece of paper marked off into cells. The rows represent times and the columns represent rooms. Beside the paper are markers and everyone present is expected to give a presentation, or be ready to.

Last year I gave a very well received talk on How To Publish An EBook. If you click the link you'll get additional links that expand upon each point. If you've got an idea of self-publishing, I hope you'll benefit from it. I'm debating upon reprising the talk this year.

There are rules to Bar Camp, but they're pretty easy. Most important is that everyone is a participant, there are no spectators.

One cool thing about Bar Camp is the scheduling app. If you direct your browser to talks.barcampgr.org you'll see it. The delightful Laura Bergells uploaded the video above that explains how the scheduling app works. The guys who put the app together are wizards.

And Jeff DeMaagd always brings amazing lighted plexiglass signs.

I just got back from the Friday night session. The coolest thing about Bar Camp is learning about things that the smart kids are doing. I feel like something of an old man and a troglodyte when I hear a kid who's been in business since 2003 describe how he uses Google advertising in a fashion that's a lot more sophisticated than most Fortune 500 companies. And he's telling BarCamp his secrets! Or another guy who's just conducted an experiment that turns business on and off like a switch.

Every year Bar Camp GR shows me the best aspects of human nature. There are folks I see pretty much once a year and it's a real joy to reconnect with them. Kudos to Ross Hunter, Dave Brondsema, Casey Dubois, Mike Mol, Ben Rousch, and Adam Tauno Williams. High praise to Atomic Object, Calvin College, Collective Idea, Cascade Engineering, CQL, Fusionary, Mutually Human, Open Source Technologies, Universal Mind, UserTesting.com, GR Makers, Grr Con, and Software GR. I love you guys.

HItting The Wall At 10,000 Feet

If you hit the wall at 10,000 feet, you're dead. When I did it at 6 inches, I was OK.

When you're at 10,000 feet, you're generally in an airplane going over 100 miles per hour. But when I hit the wall at 6 inches, I was a kid on a tricycle going a lot slower.

What has this to do with writing?

When you think about what you are writing, abstraction matters. If you think at a very abstract level, you can see entire planets at a glance, whereas at the least abstract level, you are amidst a forest of atoms. My point is more obvious in writing software than in writing novels: When you're debugging lines of code you need the atomic details. When you're laying out a system architecture, you need to be able to see the whole thing. You need to think more abstractly.

But I'm a writer, not a programmer!

Fair enough, but you cannot write without thinking. And this is about thinking about your writing.


But I'm a pantser, not an outliner!

Fair enough, but I'm pushing thinking, not outlining.

If you're writing by the seat of your pants, you are thinking about the sentence you are writing, and the next paragraph, and rest of the scene. This thinking is important for things like getting the grammar and spelling right. Or making a clear and interesting paragraph or scene. Maybe even setting up for the next scene. This kind of thinking is very similar to what a programmer does when he's in the code. It's vital, but this thinking is subject to tunnel vision. It's subject to missing the forest for the trees.

At some point you have to think about your work as a whole. A haiku or a vignette can generally be seen as a whole while you're writing. But longer works like novels cannot be seen as a whole without a higher level of abstraction.

You have to think about your work as a whole, because if you don't you won't know what to do if you hit the wall. Gentle reader, you may have never hit the wall. Good for you. I distinctly recall the time when I was about 60% done with my first novel. And I got stuck. I'd written myself into a corner and I could see no way out.

When that happened to me I consulted the notes that I had taken when I had thought through the novel as a whole before I ever started writing. These written notes showed me where I'd deviated from my originally intended story arc. They showed me where the story was going. Seeing this, and thinking at this higher level of abstraction, I could see how to modify my notes to get from where I had written to where I had to go.

In software development they talk about pseudocode, where you describe things at a higher level of abstraction so you can clarify your intent. In movies, they have storyboards, where the script is abstracted to a comic book representation. In your writing project, you need to think at a sufficiently high level of abstraction to take in the work as a whole. When you think at this level you'll see problems that you can solve at this level.

Those "notes" you mentioned; they were an outline weren't they!

Yes, they were. And if you're insistent upon not outlining, then don't. Make your notes in the way that's most effective for you.

Perhaps as a synopsis. You'll need a synopsis sooner or later, why not sooner? Or better, why not write a Product Description. Look at any book you might buy on Amazon. What you will see in every one of the 101,501 works available for purchase is a Product Description. That Product Description is what will move me to buy the work or move on. I don't think I'm alone in this.

The Amazon Product Description should be an accurate seen-as-a-whole representation of your writing project. You can examine it to decide whether it works or not. If you write it before you start your novel, you can show your friends or folks from your target market and ask whether they would buy it or not. As you write and you discover the work needs to go somewhere else, you can revise the Product Description. Later, when your work is finished and you shop around your work to some agent or editor, Or Better when you put it up on Amazon, it will be a polished gem.

If you have a Product Description that works, when you hit the wall, it won't be at 10,000 feet, because you've already thought things through at that level. If you've thought the work through in a more detailed, thorough manner, you will have solved more problems up front. If you're lucky, you'll find you hit the wall at 6 inches and you haven't even dented your trike.

 

Oh, and if you'd like to see a larger version of the penultimate image, you can find it here.