Three Egregious Outlook Problems

Originally posted 2010-03-31 10:37:09

My workplace uses the Outlook/Exchange juggernaut to manage email and calendars. This post doesn’t argue for or against that solution — it’s in place, it works, and it allows me to communicate and schedule my days. Rather, this post pleads for Microsoft to change three things in that platform:

1. They always mean \”manager,\” never \”manger\”
   OK, around Christmastime, someone might send out nativity scene notice, but most people are talking about managers. Outlook’s spell check doesn’t flag \”manger\” because it’s a correctly-spelled word. Outlook’s grammar checker doesn’t flag \”manger,\” presumably because, as a noun, it grammatically interchanges with \”manager.\” The Pareto principle should step in and flag \”manger.\”
2. They never mean \”pubic\”!
   Every few months, I get an email that intends to say \”public,\” but doesn’t. With apologies to any gynecological Outlook users out there, no one ever intends to say \”pubic\” in an email. I’m having trouble typing it right now–my fingers keep inserting an \”l\” to save me from embarrassment. Outlook should flag \”pubic\” every time and make users answer complex anatomy questions before sending any email that contains the word \”pubic.\”
3. All-day events should not have reminders that trigger five minutes before the event starts
   When my team members take vacations, they send all-day calendar events so we’ll all know not to look for them on those days. Other all-day events land in my inbox regularly. I accept them, they’re added to my calendar, and I’m well-scheduled. My calendar syncs to my iPhone, which also serves as my alarm clock. Far too often, my iPhone screams me awake at 11:55 PM to tell me that Melba will not be showing up to work the next day. I scream back and remind myself to do a better job of turning off notifications for all-day events as they come in, but Outlook shouldn’t let you send other people midnight alarms.

I’m reading Steve Krug’s Rocket Surgery Made Easy, and I watched the 25-minute usability testing demo right before I typed this post. In the video, he asks viewers to identify the three biggest usability problems with the web site. You may disagree, but the three issues above are my list for Outlook.

Surviving Meetings: The Limerick Challenge

Originally posted 2010-03-23 16:24:39

An unknown author penned a self-describing limerick (meta-limerick?) that perhaps represents the pinnacle of its genre:

The limerick packs laughs anatomical
In space that is quite economical,
But the good ones I’ve seen
So seldom are clean,
And the clean ones so seldom are comical.

You can read more about limericks here.

Isaac Asimov, who wrote about almost anything you can think of, published a series of short stories, across several volumes, about a men’s group who called themselves The Black Widowers. These men dined, discussed, dissected, and divined the answer to some puzzle in each story. The stories are quite good, and I recommend them heartily. In a few stories, until an editor convinced Asimov otherwise, one of the characters delivered a limerick summarizing a book of Homer’s The Iliad (or was it The Odyssey?).

This brings me to my dilemma: paying attention in business meetings. They often bore me, but I usually need to stay engaged and I always need to disguise my ennui. I have launched a personal campaign to summarize the gist of each meeting I attend in a limerick, while the meeting transpires. This feeds my brain while keeping me alert–after all, I have to know what’s happening in the meeting to properly summarize (and mock) it. The internal nature of the content of these limericks (company material), combined with the snarky tone that limericks require, prevents me from publishing most of them beyond my humble notebook. Here, though is an example that I wrote during a meeting with other development managers. This meeting discussed resource allocation, and since my current projects blessedly are of highest priority, I spent the meeting plucking the prime developers from other managers. They spent the meeting protesting. I wrote:

Don’t whine, do not cry, do not sob.
If your people are doing their job,
And being outstanding,
It’s our understanding
We’ll move them to underneath Rob.

Take the limerick challenge!

6 Things Apple Should Change on the iPhone–and What You Can Do Until They Do

Originally posted 2009-08-30 13:37:19

Salespeople may live from a suitcase, but I’ve lived from a PDA for over a decade. I’ve bounced from Palm to Windows Mobile to BlackBerry before landing on my iPhone about six weeks ago. I love the big, crisp screen, the usability touches, and the abundance of apps–I tap the App Store icon far too often for my bank account’s viability. This is my favorite PDA so far.

However much I fawn over my iPhone, though, I still bump against its limitations and cringe when its flaws puncture my desires. I beseech Apple to make the following six changes:

1. Make the Home Button Take a Picture

Designers talk about \”affordances,\” which Wikipedia defines as \”the easy discoverability of action possibilities\” (http://en.wikipedia.org/wiki/Affordance). In the current context, affordances describe what the device leads you to do with it. For example, the device fits easily in one hand and has an obvious speaker on the face, near the top, \”affording\” bringing it to your ear, screen to your cheek, and holding it with one hand while engaging in a phone call.

Launching the Camera app turns the iPhone into a digital camera with one large button–the Home button–aching to be pushed. The button affords pushing, and correlates to the one large button on a single-purpose camera that photographers use to snap a picture. Pushing the button, however, kills the Camera app and returns the iPhone to its multi-purpose state, losing the digital recording of the Kodak moment in the process. To take a picture, you must instead push a software widget-button that’s close to the Home button, but not close enough. With the iPhone’s accelerometer the phone can detect whether it’s being held in a typical posture for taking a picture and should respond appropriately (go Home or snap picture) very nearly every time.

What You Can Do

Camera Genius offers an alternative to the Camera app that, among other things, turns the entire screen into a camera button. No longer do you have to press the tiny widget-button, so it’s easier to take a picture. This still doesn’t address the Home button affordance, though, so you’re probably still as likely to miss recording cherished memories.

2. Put Folders in the Launcher Interface

Between the App Store and the SDK, Apple built the infrastructure to foster the creation of hordes of apps, and the development community has responded with over 65,000 of them. If you ignore the apps that synthesize flatulence, you still have hundreds of App Store apps you can install. The iPhone’s interface, however, places you three actions or fewer from only 36 apps:

1. The four apps on the bottom of every screen (tap the app)
2. The 16 apps on the first screen (push the Home button to go to the first screen and tap the app)
3. The 16 apps on the second screen (push the Home button to go to the first screen, swipe once to go to the second screen, tap the app)

Launching other apps requires either multiple swipes to find the app before tapping, or swiping from the first screen to the Search screen and plodding through the virtual keyboard in a series of taps and mis-taps to find the app you seek. You can try to memorize which screens your apps occupy in the launcher and group similar apps to minimize extraneous swipes in eyeball searches, but installing new apps slots them into the first available space. Rearranging apps across screens requires the dexterity of a pickpocket, so trying to create a logical ordering that you can memorize can be frustrating.

If Apple would build folders into the launcher interface, however, you could easily group similar apps together and be three actions away from 260 apps (the four on the bottom, 16 folders on the first screen, and 16 apps in each of those folders) and a fourth action from 256 more (16 folders on the second screen with 16 apps in each of those folders).

What You Can Do

I know of no software solutions. If somebody developed an alternative launcher, Apple would reject it from the App Store anyway. You’re stuck optimizing for your most-used 36 apps: put your four most-used on the bottom panel, the next 16 on the first screen, and the next 16 on the second screen. Then practice swiping, searching, and tapping.

3. Improve the Typing Correction

Apple chose well when it opted to trade a physical keyboard for a larger screen. Spreading Need for Speed’s raceways across more pixels outweighs the utility of the BlackBerry’s chiclets. Apple also did a good job of working within virtual constraints to try to make the intrinsically inferior software keyboard the best it can be. Popping and zooming each typed key provides instant feedback for what you type, and the built-in autocorrection seems optimized for one-off combinations (i.e. you seem to have typed the key next to the one you meant). This autocorrection isn’t configurable, however, and too often changes my text messages just as I hit \”Send.\” I once tried to text a female coworker, several years my junior, that I’d see her on Monday. \”C u mon\” became \”C u mom.\” Confessing to a pretty young blond that you think of her maternally can get you on HR’s watch list in a hurry.

Hey, Apple! Your keyboard is worse than BlackBerry’s AND your autocorrect is worse than BlackBerry’s AutoText! Pick one or the other, bot not both! I had my BlackBerry’s AutoText so well configured that I could reproduce the entire Wikipedia in about 17 keystrokes. Copy that functionality!

What You Can Do

Buy TextExpander and configure it aggressively. Don’t use it just for misspellings–put your frequently typed words, phrases, and emoticons in there. And then hope Apple will cut a deal with SmileOnMyMac to integrate into the OS so it runs in the background and affects typing in all apps.

4. Allow Apps to Run in the Background

Apple trusts no one like it trusts itself, and grants privileges to its own applications that it withholds from others’. Like the convenience store that permits only one student shopper at a time to combat shoplifting, the iPhone will allow only one third party app to run at once. Apple’s own apps, however, can shop as they like. To see an example of this, start playing a song from the iPod app, then return to your home screen and launch Contacts. Your music still plays.

The implications of this policy can neuter some third party apps, or at least hamstring them to less than their potential. Social locating apps like Loopt, for example, bring you closer to your friends and get you invited to nearby parties only while you dedicate your multi-tasking high-powered device to the single task of announcing your location. You can’t even play Solitaire while you wait for an invite. TextExpander, mentioned above, works only partly as well as it could.

What You Can Do

As the iPhone commercials say, there’s an app for that: Backgrounder App. Unfortunately, it requires jailbreaking your phone, something my risk-averse genes haven’t yet permitted me to do. Talk on the Web, though, claims Apple is discussing how to allow third party apps to run in the background. Let’s hope they figure out how to do that.

5. Give Us a Command Line and a Programming Interface

The iPhone is a general-purpose computing device, as long as someone programs the purposes elsewhere. Programming the device on the device would allow power users to exploit the computer power resting in their hands to solve problems in the moment. We don’t need access to a GUI library–just give us an editor, a command line, a place to save code files, and a scripting language: Ruby, JavaScript, Scala, or anything besides Lisp. Let me write a quick app to solve The Locker Problem or to massage my Contacts database. Don’t require me to write it on my Mac, apply DRM, and upload it to my device. Unlock the power that’s there so I can, too.

What You Can Do

This thread and this thread outline why you’ll probably never see this from a non-jailbroken iPhone.

This thread (wow–is all the good discussion on Stack Overflow these days?) lists some possibilities, none of which I’ve explored. Maybe web-delivered programming environments like Zembly or Bespin can help to fill this void, although those environments will never allow you to work with data on your iPhone (like your Contacts data).

6. Allow App Store Competition

One of the reasons for the iPhone’s success is the easy-to-find, easy-to-use app distribution model that developers can plug into without having to create their own virtual storefronts, figure out how to accept credit card payments, etc. Kudos to Apple for creating the App Store and integrating it with iTunes to ensure that every white-earbud-toting person on the planet (which is nearly everyone) has access to it. There’s an app for that because there’s an App Store for that.

Apple: now that you’ve enjoyed a year of First Mover advantage, open up your App Store to competition. Let people distribute their apps through other venues. If the App Store is truly the best solution that you tout it is, it will continue to flourish. Both developers and consumers will use it because it’s better, not just because it’s the only option. Most people will still use the App Store exclusively, and the competition will help direct your efforts to improve how the App Store works.

What You Can Do

Jailbreak. I realize that this item essentially requests Apple to endorse and institutionalize jailbreaking. If they do it, however, they can control it. They can divide trusted apps from untrusted apps. They can have a way for customers to reset their devices to \”trusted only\” and make that a standard support procedure. They can embrace the tinkering without undermining the foundation of their product. Think of the relationship between Mac OS X and MacPorts, in which Unix gear heads can set up an alternative to the Mac OS X environment in a proceed-at-your-own-risk scenario. All I’m asking for is an iPhonePorts.

Conclusion

Some of what I seek will probably never happen, as it would require Apple to relinquish more control than they’re willing to cede. They continue to head down a path of more, not less, control, and their financial results seem to reward that strategy. They as yet have no incentive to change course on the control issues. Nudging them from that course will require stiffer competition from Android, Palm, or some other competitor.

Apple will continue to grow the iPhone, however, and I think we’ll soon see background threads (which will enable improved autocorrection), launcher improvements, and at least improvements to the App Store. In the mean time, I’ll continue to live from my iPhone.

The Elite Eight Development Principles

Originally posted 2009-04-18 03:11:31

As a management team, we recently crafted and presented a list of development principles for our developers to follow. The goal was to provide vision and direction, not to dictate the outcome of every scenario. Here’s a somewhat sanitized version of what we presented.

The Elite Eight Development Principles

1. Code with your teammates in mind.
2. Don’t break the build.
3. If it ain’t in source control, it doesn’t exist.
4. If it ain’t testable, it doesn’t work.
5. If it ain’t repeatable, it was never done.
6. Think more, write less, and keep it simple.
7. You’re better with tools.
8. Share what you learn.

#1: Code with your teammates in mind

\”It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.\” — Steve McConnell

If developers truly understood and followed this principle, we could shrink this list from \”Elite Eight Development Principles\” to \”Only One Development Principle.\” You’re going to write code and move on, whether to another company, another team, another project, or simply to Disney World for a week, and somebody else will have to update, add to, refactor, or fix bugs in your code. Have compassion for the developers and analysts who come behind you. Don’t make them pick through convoluted code, straining to figure out how it works — do your best to flatten their learning curve.

Here are some thoughts on how to code with your teammates in mind:

• Use the automatic formatting set up in the IDE so the code looks consistent.
• Heed and eliminate compiler and static analyzer errors and warnings.
• Name your packages, classes, variables, and methods meaningfully.
• Use libraries appropriately.
• Avoid magic numbers.
• Comment anything that smells weird.
• Don’t copy and paste.
• Reuse common methods appropriately.
• Refactor aggressively.
• Don’t assume that everyone has operator precedence rules memorized.
• Use javadoc.

These are just some thoughts — you’ll think of more as you code with this mindset. Focus not on proving your cleverness, but rather on how to make life easier on the next coder to touch your code. If you can’t muster kind feelings for them, then at least do as the C2 Wiki says: \”Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.\”

If javac doesn’t care about white space, why should I?

Few things ignite programmers’ ire more than discussions of tabs vs. spaces or the appropriate placement of curly braces. No formatting rules, whether curly brace placement, equals sign alignment, or the number of spaces per tab ever achieve universal preferred status. Since no formatting standard is universally correct, and people will have beefs about each possible nuance of any formatting scheme, and the compiler has no opinion and accepts correct code no matter how it’s dressed, why bother trying to format according to a standard? Isn’t function more important than form? Isn’t content what matters?

Absolutely. Content is indeed what matters, and function trumps form for everything except Donald Trump’s hair. That, however, is the point: code that differs in its format draws attention to how it looks and away from what it does. Imagine, for example, that you were reading John Grisham’s latest novel, and each page used a different typeface. Text on even pages was justified, while text on odd pages was flush left, ragged right. Some chapters were named, while others were merely numbered. These formatting oddities might not ruin the story, but they would annoy you and detract from the story. They might even annoy you more than the fact that the book ends abruptly, dangling many story lines and convincing you that the editor had called and told busy John that his time was up and that the story had to be shipped as-is to the printer, and money would roll in regardless of whether the story actually reached a literary conclusion.

In the same way, code that varies in formatting draws attention to its formatting differences and slows developers’ understanding and flow without providing any offsetting benefit. If developers instead agree to disagree on how pure code should be formatted, and set aside their formatting preferences to unite on how to arrange the curly braces, ;s, equals signs, and spaces in the shared code base, everyone can focus on the content of the code and produce more of it. Also, any energy that isn’t spent on formatting wars, in which developers race to overwrite each other’s latest check-ins with reformatted versions of the same code, can be spent on writing new code, fixing bugs, or reading John Grisham’s latest novel. Everyone wins, especially John Grisham.

A tale of copy and paste

Clipboards, which allow you to cut or copy text from one virtual place and paste it into another, represent a great advance in computing. Much of the criticism surrounding the iPhone, in fact, laments the lack of cut-and-paste (the rest of the criticism is that all of the free games on the App Store suck). Why should developers not use this powerful tool that promotes more aggressive refactoring, causes fewer typos, and aids in reusing code? Although it’s been said that \”pasting code from the Internet into production code is like chewing gum found in the street,\” developers should indeed liberally use the clipboard properly. Misusing the clipboard, however, gets developers in trouble and bloats a code base. Against this type of usage I presently lobby.

In proper usage, a developer cuts common code from a class and refactors to a base class. In improper usage, a developer copies the whole class into a new file and changes a few lines here and there. In proper usage, a developer moves code within a file to be cleaner and more readable. In improper usage, a developer copies code to multiple places within a file to perform the same steps in multiple places. In proper usage, a developer tightens the code. In improper usage, a developer loosens the code like a belt after Thanksgiving dinner.

I once worked with a developer who cut and pasted like a kindergartner on craft day, and his code sagged with duplication and smelled like Elmer’s. Though he peppered me with questions about best practices and claimed to be dedicated to continual improvement, he shunned any of my vocal entreaties for reform and continued to scissor and glue-pot his code.

Since I had spent some time programming the Windows shell in those days, and since his dedication to workstation security resembled PETA’s dedication to preserving the beauty of fur coats, I hacked some code, waited for him to go to a meeting, and installed it onto his unlocked computer. The code injected itself into his text editor and lay dormant until he tried to paste anything. Any attempts to paste triggered my code, which blocked his paste attempts. Instead, his editor would display an error and remonstrate him for coding by mucilage. This frustrated him for a time, but he learned to refactor and reuse code appropriately!

Parenthetically, he never learned to lock his workstation. He eventually had to turn down the volume on his speakers when I reprogrammed his \”Start\” button to display a different, rhyming word, and to play a vulgar sound any time it was depressed. I also created my own administrator ID on his computer so I wouldn’t be bothered by those rare instances in which he remembered to lock his workstation. Want the password?

Comments on comments

Debates rage around whether and how to comment code. Some folks insist that all code be commented, while others disdain comments as superfluous, potentially incorrect, and violations of the Don’t Repeat Yourself (DRY) principle. Blowhards from both sides, however, seem to agree on a few things:

• Method names and variables should convey their
  usage and intent
• Implementations of known algorithms (e.g. Quick Sort) should be commented as such, so that reviewers will know that deviations from the algorithm represent defects that should be corrected
• Comments that describe the intent of code are usually helpful
• Any code that can’t easily be read and understood by reasonably proficient developers should carry explanatory comments

Steve McConnell wrote, \”Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.\”

#2: Don’t break the build

\”Don’t break the build.\” — Microsoft

Broken builds break spirits, stop work, and undermine trust. You can’t compile a broken build. You can’t deploy a broken build. You can’t test anyone’s changes in a broken build. You can’t run a broken build on your workstation. You can’t develop against a broken build. If the builds break too often, people quit updating from source control, causing more merging headaches. Builds must always work. When the rare but inevitable broken build surfaces, developers should drop everything and fix the build as quickly as possible. Buildable code is the foundation for what we do and should be treated as sacrosanct.

Note that broken tests equal a broken build. Failing tests mean that the build is broken.

We have a continuous integration server that builds our code almost constantly. It sends out notifications any time the builds break or the tests fail. Heed those notices. Make it your business to keep the build alive and well.

#3: If it ain’t in source control, it doesn’t exist

\”I consider this the golden rule of source control: Check in early, check in often.\” — Jeff Atwood

OK, so the \”ain’t\” is a gratuitous attention-getter. Source control merits attention, though. Anything that’s not in source control simply does not exist with any appreciable permanence. Things outside of source control are easy to lose, easy to overwrite, and impossible to reproduce. Check in code early and often. Don’t ever lose a week’s worth of work, or even a day’s worth. Everything has to be in source control: code, deployment scripts, database schemas, SQL scripts, shell scripts, et al. Even rush changes must go through source control: retrieve the latest code from the source control repository, update it, check it back in, and THEN deploy. It doesn’t take any longer, and it ensures that someone else’s change — whether rush our routine — won’t overwrite your heroics.

Out of control

At one place I worked, another team developed a project over many months, and never checked their code in to source control. You’re probably expecting me to say that they lost all their work the day before deployment and were roundly beaten and fired, but you’re wrong. No work was lost. The project went to production and worked well . . . about a month after development and testing had completed and the customer had been notified that their project was going live. The intervening month was spent trying to determine which of all the versions of the source files on all the developers’ hard drives represented the correct versions, checking in and rechecking in files furiously, trying to get the project to build, and deploying the application over and over into the testing environment and retesting and yelling at each other that they still had the wrong version of Foo.java or Blat.properties. I sat amidst the chaos like a sanctimonious schoolmarm and tut-tutted and tsk-tsked just under audible levels while I calmly and dutifully checked in my changes, day after day, and left work on time while they continued late into the night, checking in random files like overdue library books.

Imagine the cost of that additional month, incurred because they shunned source control. And they were lucky that the ramifications weren’t worse.

#4: If it ain’t testable, it doesn’t work

\”Why don’t people like testing? Well, the traditional way of testing is tough to take. You write what seems to be perfectly sensible code, then you write a test and the test tells you that you failed. No one wants to hear that. Let’s turn it around. Write the test first and run it. Of course it fails. You haven’t written the code under test yet. Start writing code. Keep testing. Soon, the test will tell you that you’ve succeeded!\” — Michael Feathers

Another gratuitous \”ain’t,\” but I like the parallelism. We’ve really struggled as a development shop to move to test-driven development, and we’re missing the behavior-driven development wave. The excuse has been the large, legacy code base, but we’re seeing plenty of new code without automated tests. One of our teams, on the other hand, continues to cover high percentages of their code with unit tests. Some folks get it, and some don’t. We all can, and must, get on board with this, though.

We should strive to prove all our code. Testing code demonstrates that it works. Repeatedly testing code demonstrates that it still works, despites any changes applied to it. Automatically testing code demonstrates that the code works, over and over, after each change. Automatically testing code outsources the mindless part of software testing to the computer, which never tires, never complains, never forgets steps or goes on vacation during critical parts of a project. Instead of riding to Production on hope, we can ride on the knowledge that we’ve proven our code.

Detractors say that automated unit tests take longer and don’t provide enough value. Let’s examine these.

Takes longer

No definitive answer exists on this subject. Some say writing the test code does indeed take longer because you’re writing extra code. Others say it takes longer to write unit tests at first, but as you continue writing tests first, you reach levels of proficiency that make the whole coding process faster. Still others say that writing tests first is faster from the outset, that defining how the code should work through writing the unit tests first makes writing the code extremely fast, and the overall coding time shrinks.

Which of these answers is correct? Probably all of them. Just as we all wear different hat sizes and prefer different John Grisham novels, we all have different experiences with writing tests first. The right answer isn’t whether or not writing the tests first takes longer. The right answer is that writing the tests first makes better code that we can automatically and repeatedly prove to be correct before we deploy it to Production. Not writing any code is even faster than writing code without unit tests, but we don’t often argue for that approach.

Not enough value

When I write a method, say, to accept a string that represents a zip or postal code, validate that it represents a correctly-formatted zip or postal code, look up the associated region in the world in a database, and return that region’s latitude and longitude, I build that code right before my eyes. I know each step of it. I know that when I try running it and type \”123\” into the web field and click submit, that I get an error that the zip or postal code is not correctly formatted. I know that if I type \”123456789\” into the same web field and click submit, that I get an error that no region has that zip or postal code. And I know that if I type \”8675309\” into the same web field and click submit, that I get the name \”Jenny\” displayed under for the latitude (this is a test database, after all). But each time I want to test it, I have to fire up my application server, navigate to the web page, type data into the web field, and click submit. And if the database is down, I can’t verify that my zip or postal code format validation code works.

If I’m writing tests first, however, I’ll design better code. I’ll separate the zip or postal code format validation code from the region lookup code. I’ll pass
various values to the routines, including ones I can’t type into a web field (like null, or Supercalifragilisticexpialidocious, which I can never spell consistently), and it doesn’t cost me any extra time or effort to retest all those values. I can mock the database connection, so I don’t need to rely on the database being alive or containing the right values. And I can run these tests, over and over, until I prove my code correct.

What’s more, I don’t have to worry about another developer unwittingly breaking my code. If he or she breaks it, the tests will fail without any extra effort on my part. In fact, I don’t even have to know about it. The build server will build that developer’s changes, run my unit tests, and announce the broken tests for that developer to fix.

Let’s suppose, too, that many months from now, the code breaks in Production because some user named ttutone actually types in 8675309, and our zip or postal code format validation code accepts it, but the database lookup code fails because you can’t reach Jenny without an area code and we spew an ugly stack trace to the logs and an incomprehensible error to the user. The developer working Production Support will first fix the tests, and then fix the zip or postal code format validation code, so we’ll never again face this error in Production.

Unit tests provide value not only when you’re developing the code, but again and again throughout their life, so long as the build server is running.

#5: If it ain’t repeatable, it was never done

\”I am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand.\” — Douglas Adams

Early in my technical career, I worked with someone who wrote batch files for everything he did so he could repeat them at will. I worked with someone else who kept a copy of Notepad open filled with one-liners that he could cut and paste into a command prompt, rather than retype commands. I thought them both daft, and reveled in my superior memory that I could memorize command-line switches and pipes and redirects and commands and didn’t need to resort to stupid memory tricks to do my work.

I’ve gotten smarter with age, left the coding for people more adept at it, and now I stick to emails, documents, and spreadsheets. I learned along the way, though, that computers excel at repeating things, and humans don’t. We get bored. We forget things. We rarely do things the same way each time. Computers, however, obediently do exactly what they’re told, exactly the same way, every time.

Little of what we do is done only once, whether it’s building code, deploying code, populating databases, or writing emails. Things that must be done many times with predictable outcomes (like deploying code) will quickly become undone if they’re not absolutely repeatable. If, for example, a code deployment requires me to edit a properties file after the build but before copying the distribution bundle to a server, I’ll forget from time to time to edit the properties file. Or someone else will forget. Or someone will fat-finger the edit and the information in the properties file will be wrong. Or someone will be stuck using vi for the first time and not actually save the edited file. In all these cases, the deployment will undo the work of any previous deployment. Each thing we do must be repeatable.

Speaking of repeatability . . .

My teenage son recently called me from his grandfather’s house asking about the Mac OS X built-in command \”say,\” which accepts a string as an argument and speaks aloud whatever text you’ve passed to it. He wanted to know how to make this command repeat itself infinitely, so I walked him through the shell commands to do that. Like the mysterious stranger offering the salt grinder, however, I made sure to tell him how to stop the loop by pressing Ctrl+C.

Some time later, he called me again. To a backdrop of an incessant chorus of \”Grandpa is an idiot,\” he confessed that he forgot about Ctrl+C, and instead just closed the terminal window, and now he couldn’t make the computer stop impugning his grandfather’s intelligence and was imperiling his own inheritance. I tried to teach him the finer points of \”ps\” and \”kill,\” but that stayed just out of his reach. I finally had to tell him twice to reboot (the first time he just turned off the monitor, of course) for the sound to go away. And I think that’s why hash codes in C must be salted.

#6: Think more, write less, and keep it simple

\”There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.\” — C. A. R. Hoare

This principle was inspired by a blog post from one of our developers: Back to Basics.

The early days of Linux attracted legions of computing elitists that felt ease-of-use reflected poor robustness or scalability or something, or maybe they just wanted everyone to know how smart they were. Thankfully, those snobs have moved on to Perl, which is too hard even for them and where no readable line of code passes code review. Much of the effort in the Linux space over the past few years has been to make it easier to use. Package management allows simple installation and removal of software packages and their dependencies. GUIs, once scorned, have been instituted for many configuration tasks. Desktop environments like Gnome and KDE have blossomed to rival, and in some instances surpass, the usability and simplicity of Microsoft Windows or even Mac OS X. One of the factors in Linux’s command of the server space, and its intrusion into the desktop space, is that the tools to configure and use it have gotten simpler.

Simple minds or simple approaches, however, do not produce simple artifacts. Simplicity requires careful thought and insight. Our development process devotes an entire phase — Design — to the portion of the software development lifecycle dedicated to careful thought and planning.

Take the time to think something through before banging code into your editor. Refactor code mercilessly so that you have less code doing more things, though not at the expense of readability. Keep in mind the statement made by Martin Fowler, author of Refactoring: \”Any fool can write code that a computer can understand. Good programmers write code that humans can understand.\” Another computing guru and cofounder of Apple, Inc., Steve Wozniak, said, \”My style with projects has always been to spend a lot of time getting ready to build it.\” In fact, Wozniak was most famous for the simplicity of his designs that used fewer chips than anyone else could imagine, until he thrilled the world with his dance steps on this season’s Dancing with the Stars. Actually, one judge said he danced like a TeleTubby, so maybe he’d prefer that we remember his chip design skills.

#7: You’re better with tools

\”Man is a tool-using animal. Without tools he is nothing, with tools he is all.\” — Thomas Carlyle

Stephen Covey admonishes us to sharpen our saws. Carpenters and auto mechanics admonish us to use the right tool for the job. Monster Truck fans tote the hammer they received as a gift for dropping out of sixth grade everywhere they go, and steal duct tape by the bushel from Walmart, so they can fix cars, mend fences, and patch their overalls. They all understand that they’re better with tools.

Search for tools. Learn how to use them correctly. Spend some time in their documentation and forums to understand their breadth and power. Apply them to your work.

We support a standard toolset: Eclipse as the IDE, AccuRev for source control, Cruise Control for continuous integration, TeamTrack for ticket tracking, Java as the language. Learn those tools.
Use them. Follow the standard procedures to keep your environment up to date. This way you can mesh with other developers, get support when you have issues, and focus on delivering projects.

What if you’re more adept with other tools? We want developers to be at their best, but also to fit into the team. The standard toolset can provide that. Additionally, you can judiciously augment your environment with other tools while still accomplishing that. You must follow two important rules:

1. Keep your standard environment up to date using approved procedures so you have something to fall back on and can stay in sync.
2. Don’t let your deviations from the standard toolset affect the team.

What does that mean? Let’s go through some examples:

• Use IntelliJ for code editing? This can be done as long as you:

• Don’t change the file structure for Eclipse projects, package names, et al.
• Either duplicate the standard formatting rules in IntelliJ or reformat in Eclipse before checking in.

We should always be searching for better tools and bolstering our toolsets. Just keep the two rules in mind and we’ll succeed together. Don’t forget to share tools you find — see principle #8.

#8: Share what you learn

\”If you think education is expensive, try ignorance.\” — Derek Curtis Bok

When our boss began his career, only three mainframes existed in the entire world, and two of them had run out of DASD. Any technologist worth his or her punch cards could know all there was to know about computing. Nowadays, Cisco has threatened to shut down the whole Internet unless at least one new web framework appears on SourceForge daily. Developers everywhere have met that challenge head-on, and now SourceForge threatens to run out of DASD from trying to store all the new web frameworks. Technology has grown too large, and continues to grow too fast, for any one person to know all there is to know about computing.

That doesn’t mean you shouldn’t try, however. Learn all the time. Read RSS feeds. Read books. Read articles. Try new technologies. Know what people are buzzing about and why they’re buzzing. Pay attention to who the industry luminaries are and what they’re saying. Understand what tools are losing favor and why. Know what tools are gaining favor and why. Feed your head at every chance.

You still won’t keep up. Turn to your peers. If they’re doing what you’re doing, then they’re learning, too. Trade perspectives with them. Swap knowledge and lessons learned. Tell them what you’re chasing and why. A work environment can become a collective brain. We provide a wiki and a discussion forum, and encourage developers to hold lunch-and-learns on new technologies they’re exploring. We’re trying to drive a culture of learning, and need learners to push the stagnant. Pay attention, and pass it on.

Closing Thoughts

The Elite Eight Development Principles on their own won’t guarantee great code, happy developers, or a chicken in every pot. Dedicated adherence to these principles, however, will lead to better decisions, fewer mistakes, and a more cohesive environment. These principles will enable great minds to produce great code. They represent management’s vision for software development.

Some final quotes:

\”Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.\” — Eric Raymond

\”The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.\” — Fred Brooks

\”My message to the serious programmer is this: spend a part of your working day examining and refining your own methods. Even though programmers are always struggling to meet some future or past deadline, methodological abstraction is a wise long-term investment.\” — Robert W. Floyd

The Fate of New Computers in My House

Originally posted 2008-12-12 07:27:04

In recent months, two computers in my home reached the ends of their useful lives. The first was the HP desktop that my children use. They’ve loaded so many game demos on it over the years that it had become painfully sluggish. I was going to wipe and reinstall the OS, but the DVD drive doesn’t work. I had replaced the drive some months ago, and it worked for a week then quit working again, so it’s probably an issue with the motherboard. The computer is old enough, and my time is valuable enough, that it was simply cheaper to give the computer to a geeked-out nephew and buy a Lenovo on sale for less than $500 (3 GB RAM, 500 GB hard drive, 19\” monitor).

The other computer that died was my wife’s HP laptop. The connector on the power cord was bent in some sort of accident, which can easily happen in my home (three adults, five children, three dogs, one cat, and a parrot), and I don’t know if the problem is with the power cord or the connector on the computer, but no matter which it would be expensive (both to the wallet and the schedule) to buy replacements and troubleshoot the issue. Old laptops don’t merit that kind of hassle. So again I went shopping and found a $499 laptop–again, a Lenovo–with 3GB RAM, 300+ GB hard drive, and all the power my wife needs to do email, buy things on the Internet, and update her Facebook status.

Both these new computers are much more powerful than their predecessors. They’re sleek, robust, and satisfy all my wife’s and children’s computing needs. I should be a hero, but I’m not. They hate them. The culprit? Vista. They say, \”It’s slow and it doesn’t work right.\” Apparently, they’re not the only ones saying that, as Windows market share drops below 90%.

My children use two applications: Firefox and Word. They surf the web and they write papers for school. They’ll soon be moved to OpenOffice.org. My wife uses 3 applications: GMail (through Firefox), Facebook (through Firefox), and OpenOffice.org. Oh, and she shops, all through Firefox. I’m switching them both to Linux this weekend, and I’ll regain my hero title.

Technical Teens

Originally posted 2008-11-11 12:33:17

My oldest child turned 15 yesterday. We had planned a family party for him–eat barbecue, open presents, eat cake–but we ended up canceling after he cussed me out at church the day before. He doesn’t live at home, and we decided he’d rather not spend his birthday with his parents. You see, this child has bipolar disorder, oppositional defiance disorder, and obsessive compulsive disorder. I could tell you stories. Parents of children with mental illnesses would nod their heads knowingly, and the rest of you would stare in horror and disbelief. If you’re interested in what life is like for parents raising a bipolar child, you can read my wife’s blog at http://parentingyoyos.blogspot.com.

Sidebar: My wife came up with the name \”Parenting Yo-yos.\” I find it clever, as it uses \”yo-yos\” both as a verb (parenting goes up and down) and as a noun (these children we parent are a bunch of yo-yos).

Raising a teenager accustoms parents to multiple displays of anger, resentment, and disrespect: doors slammed, eyes rolled, curses muttered. Raising a bipolar child widens the scope of the hatred-filled displays: stools thrown, doors destroyed, police defied. In all these actions, teenagers signal to their parents that they are independent, that they resent parental influence, that they no longer like their parents. Our son showed us yesterday, though, that teens in today’s technical age have a new way to tell their parents they hate them.

He deleted us both from his Facebook friends list.

Expiring Ink?

Originally posted 2008-05-07 11:56:22

I walked past our office plotter the other day and noticed this message on the console:

This picture is blurry but says, \”Cartridges will expire in days: 8.\” Are you kidding me? When did ink start expiring like 2% milk? I’ve heard of invisible ink, but expiring ink? How dumb do they think we are?

One of the IT guys happened by while I spluttered about the stain of injustice. He opined that, since plotters weren’t pressed into frequent enough use to turn over enough ink cartridges to net enough profits, HP had to invent another way to extract purchase orders from data modeling departments. Hence, the arbitrary chromatic shelf life.

Before someone hastens to HP’s defense to explain that old ink could clog nozzles, let me explain that I’m not buying. I collect fountain pens, and have wells of ink that haven’t felt the dip of a nib in years. These inks still flow smoothly when pumped into sudden use. Perhaps Mont Blanc knows more about how to make ink than HP, but Mont Blanc charges a fourth the price for twice as much ink. HP should spend some of their ink profits on research and development to catch up to last millennium’s technology. Besides, the HP inks print brilliantly the day before their expiry, artificially dying in a moment rather than fading away as you’d expect.

Recently I found myself in need of a new printer. After inspecting and analyzing my local Circuit City’s offerings last week, I bought an HP printer touted as the newest and latest model. I liked it so much that I went back this week to buy another. It was no longer offered. In fact, none of the printers I saw last week still commanded shelf space–they’d all been superseded by later models from the same companies. I guess we should laud inks for at least lasting longer than the printers that spew them!

Capital NOT

Originally posted 2008-04-28 01:28:26

People are always careful when typing emails.
People are now always careful when typing emails.
People are not always careful when typing emails.

Emailers often both read and write the above statements synonymously, simultaneously asserting and negating their intents as they saunter through communication wreckage. I’m not sure why correctly typing \”not\” or correctly reading \”not\” poses such a challenge, but I bump into this problem at least weekly, if not daily.

To combat this problem and avoid subsequent clarification email threads, I now (NOT \”not\”) capitalize NOT every time I type it in emails. The discomfort of holding down shift ascertains that I truly mean to type NOT. Readers, too, are much less likely to miss a capital NOT than a lowercase \”not.\” I have begun encouraging colleagues to follow suit.

Registering Peek-a-Boo Process Throb

Originally posted 2008-04-22 05:57:05

Last week macZOT offered a discount on an application called Peek-a-Boo Process Throb. I’d never heard of the application, and am not yet sure how often I’ll use it, but I found the concept interesting, the execution well done, and the price negligible, so I paid the registration fee. Some time later, I received my registration key in an email, so I copied the key to the clipboard and command-tabbed to Peek-a-Boo to figure out where to paste the key. The following dialog popped up:

How cool is that? I’m facile enough with a computer that I’m confident I could have navigated the menus and found where to paste the key, but I found not having to do so gratifying. I’m sure this feature doesn’t consume many CPU cycles, either. Presumably, Peek-a-Boo checks the clipboard only if it’s not registered, and then only when it first receives focus. Once Peek-a-Boo is registered, the code can lie forever dormant.

Nice touch, Peek-a-Boo developers!

Safe 0.5 Released

Originally posted 2008-04-09 13:16:31

I just released version 0.5 of Safe, the open-source command-line password management program written in Ruby. This version adds diffing and merging Safe password files. I keep my Safe file on a USB thumb drive, but I also copy it to the various computers I use in case I don’t have my USB thumb drive with me. Sometimes the files get out of sync. Now I can diff and merge the files.

I also ran into some problems with passwords not authenticating. It seems that the XML parser was behaving somewhat differently, adding white space to the salt and hash used to authenticate your master password. After kicking around various options, I moved the salt and hash to attributes of the <safe> root element, which is really where they belong. This fix in not backward compatible, so you need to manually edit your .safe.xml file (back it up first!), cutting and pasting the <salt> and <hash> elements as attributes of <safe>, like this:

<safe salt='abc123FGH987=' hash='123456abcdef123456abcdef'>

(Note: I need to update the instructions on the web site, which are automatically generated from the README–I just noticed that my embedded <s and >s aren’t being translated.)

Update: web site fixed