precisematters

Joel Spolsky says everyone should learn C. He even gives some compelling reasons. Now, don’t get me wrong, I truly respect Joel. But he’s wrong. I believe he’s using hyperbole. Let me tell you why I think he knows he’s wrong.

Abstraction is a very important part of computer science. Without the improvements and advancements in our layers of abstraction you and I wouldn’t be here today. Meaning, I wouldn’t be here typing a blog entry, and you wouldn’t be here reading it. Of course no one reads my blog posts even though we have come up with a lot of amazing abstractions and thus I am here typing them.

Without 3rd generation programming languages and TCP/IP, not to mention about a dozen other abstractions, the web wouldn’t exist. Abstractions allow us to forget the problems and challenges those who’ve gone before us have already solved. Instead we can focus on solving new problem, perhaps in domains more relevant to culture or business. To Joel’s point, sometimes the abstractions we build on break. Then if we don’t know some of the inner workings, we are hosed. But like most things in life, none of our abstractions are perfect. And they weren’t meant to be. Abstractions just have to be solid enough for us to build on top.

“Everybody should learn C.” Most superlative statements can easily be proven wrong. Notice I didn’t say all superlative statements can easily be proven wrong. Kidding aside, I am certainly not claiming that C isn’t useful to some people. Nor do I think people won’t ever cross over layers of abstractions. That’s part of the feedback cycle that improves our abstractions. However, the fact is most of us don’t realize the abstractions are there in first place. That is somewhat the point.

I think I coined the phrase “entropy happens.” My father has a degree in Physics. So I learned about entropy when he helped me with my elementary school science fair project. We took a cookie sheet of coins all face up. Then we flipped the coins all at once. I recorded the number of heads and tails. We continued flipping and recording for several iterations.

What a simple way to see that a system of order naturally moves to disorder when energy is applied! I didn’t realize at the time but entropy also applies to life. As I grew older and wiser about the world, I observed life contains many examples of systems moving from order to disorder. Thus, I fashioned my geeky substitution for the well known phrase “s*** happens.”

Signal vs. Noise youtubed a spot by Ira Glass. It reminded me that entropy also takes its toll on software. This can take many forms. 37signals has long highlighted feature bloat as one of entropy’s victories. Developers know code bases also trend toward disorder.

These are just a few examples of disorder in code that come to mind:

• responsibilities of methods
• responsibilities of classes
• duplication of behavior
• high coupling

I want to guard against promoting refactorbation. I still don’t know exactly how to find the right balance between prioritizing features vs. clean code. Sure, Nobody Cares What Your Code Looks Like, except other developers. But, I’ve inherited enough code sets to know that some degree of cleanliness in code is important. The priority is undoubtedly:

1. Features must solve pertinent business problems.
2. Code should be clean enough to be maintainable and extensible.

In both cases we are fighting entropy. Will you be an entropy buster?

I love the way the 37signals guys handle popularity. The web can be a tough place; Jeff shares about some of the missing voices because of the popularity problem in the blogosphere. Maybe the web isn’t immune to the pattern of popular culture exploiting the lives of celebrities as we see in the news everyday. But I don’t think that’s the whole story. He wasn’t referring to written communication exclusively, but Paul Graham told us people with new ideas would be despised.

I think there are two main issues at work here.

1) Every communication medium has strengths and weaknesses. Written communication fails to convey context because it’s asynchronous and one way. Always be sure to choose the right communication medium. Any form of “publishing” is inherently asynchronous. Blogs are personal publications. Of course, I’m not advocating all asynchronous communications, like blogs, should be eliminated. Just know its weakness.

2) Communication driven from passion results with an intensity that can easily be mistaken for something negative.

My blogging certainly hasn’t reached any such level of popularity to have dealt with these issues. However, I can remember specific cases of verbal and instant message communications in which I’ve been misunderstood as both arrogant or defensive because of my strong passion about creating software. Passionate infatuation is easily confused with love. Similarly passion in communication, especially in our beloved blogosphere, is often confused for something else.

I share Jeff Atwood’s obsession with maxmizing productivity with multi-monitor set ups. I’ve experimented with several utilities. Lately, I’ve used Ultramon and Gridmove most. After dabbling with the utilities for several months now, I have concluded the single feature I want most is moving windows between monitors. I hate making mutually exclusive decisions like which monitor a given application should reside by default. I often need two random applications on different monitors side by side, which may well contradict an app’s “default” location. So, I like to be able to pop maximized windows between monitors instantly and effortlessly.

At work I have two 1280×1024 monitors.

I don’t care much for the other features of either Ultramon or Gridmove. Maybe for truly high resolution screens (higher than 1280×1024) gridmove would be handy. I like using Gridmove at home on my 1680×1050 wide screen to snap windows into a normal width frame. Although, I don’t consider 1680×1050 high enough resolution to fully leverage Gridmove. Gridmove can accommodate my most important feature. However, it doesn’t perform well at simply moving maximized windows between monitors.

Since I find window switchers (Vista Aero, ALT+TAB, mouse click) much faster than the taskbar at switching to the desired application, I have little use for Ultramon’s smart taskbar. And while the wallpaper and screen saver features of Ultramon are cool, they have no utility.

Between Ultramon and Gridmove, I believe Ultramon does the best job of switching windows between monitors. Then I met Winsplit Revolution.

Ultramon never worked for me in Visual Studio. Winsplit worked with VS instantly. The icons Ultramon adds to the title bar don’t show up half the time and yet still worked if you clicked where they were supposed to be. Other times the Ultramon-blind-click-of-faith did not work. To be fair, I was running the beta as recommended for Vista. Oh yeah, and Ultramon cost $40, while Winsplit is free.

I changed the default hot-keys in Winsplit for moving the selected window to the monitor to the left, right, and to maximize from:

• CTRL+ALT+Left
• CTRL+ALT+Right
• CTRL+ALT+NUM5

to

• CTRL+ALT+Q
• CTRL+ALT+W
• CTRL+ALT+D

Now all the important commands are one handed. For example, if I am working in Outlook and want Onenote on the opposite monitor, all I have to do is:

• ALT+TAB, mouse click the window with the purple onenote icon
• If it’s on the same monitor as outlook, CTRL+ALT+(Q or W) depending on if i need to move it right or left
• If for whatever reason it isn’t maximized, stay on CTRL+ALT and press D

Brilliant!

The old saying has sticking power. It resonates. It feels true. It’s hard to argue with.

I make a habit -read obsession- of finding the common themes and intersections of different readings. I was in a leadership class for two days at work this week. The discussion was excellent. Someone used the phrase “perception is reality.” I immediately began reconciling this with my main conclusion of the ebook Getting Real - that running code is real, everything else is not. I had a problem. If only running code was real, what about perception? Is the old saying wrong?

A better question: does the word “real” in my conclusion mean the same thing as “reality” in the old saying? Sort of.

Perception is reality.
Perception is not shared reality.
Shared reality is what counts.

Getting Real attempts to reduce the variance of unshared realities by preferring running code over metadata about running code.

Here is the google search for “cya agile”. ’nuff said. This is so short it may be a waste of a blog post. But I feel better getting it out there.

I finally completed the amazingly long series of blurbs Getting Real. The folks at 37 signals have given us many ingredients in their recipe of success. I’ve never worked for a small software product company or in an agile shop; so I have to imagine what it must be like. Here are some of my personal highlights:

Honesty
One theme is dealing honestly with customers/users. It’s refreshing to hear companies advocate for honesty. They really believe honesty and openness with customers results in the best economic outcome for both parties.

Simplicity
Another important theme in the series is simplicity. Software has too long suffered from bloat. See! There is even a wikipedia article about it! Getting Real has a clear message regarding simplicity. Software should be focused, simple, and not attempt to do everything or please everyone. This is the only way software has a chance to do anything, any single thing well.

Reality
Running code is real. Everything else is not:

• pagespecs
• use cases
• user stories
• estimates
• project plans
• SLAs
• UML

Some formalization of planning and design is good. However, running code provides real feedback which is the most important factor in creating software that gives people something they want.

I’ve been asking the why question a lot lately. My mind locks in on topics like these when I encounter them as themes in different readings. Lately I’ve read Paul Graham’s essay How to do Philosophy and Joel’s blog post Five Whys. Asking why is a great exercise.

Why am I doing this?
Why did this happen?
Why am I doing it this way?
Why is this so hard?