Writing Software for the Keyboard

Over at Punished by Rewards, Pete’s thrown out some ideas on how to improve the Remember the Milk web user interface.  Actually, maybe it’s not so much how to improve it as it is complaints about how it is currently designed.

Either way it is interesting to see how one’s personal preferences around the use of software in general colour one’s opinions about how software is designed in particular.  I don’t pretend to know what the RTM design team is thinking but one thing that is relatively clear to me is that they’ve designed the website to be manipulated using the keyboard, not the mouse.  This is a particularly interesting design choice given that web design typically favours mouse-based navigation and interaction.  Also, for people who use OSX regularly (which basically treats the keyboard as an optional accessory) it is easy to see why the mental model of RTM does not suit their typical usage patterns.

That being said, does this mean that RTM is designed with a particular set of users in mind?  Again, without being privy to the design decisions of the development team it’s hard to say conclusively.  What I have noticed is that the RTM user experience does seem to be geared towards the power user.  Using the Windows metaphor as a guide, we see that novice users begin with the mouse and progress increasingly to shortcut keys and keyboard interactions as their familiarity and speed increases with experience.  The concept here is that the hand movement from keyboard to mouse is an expensive operation and with experience can be avoided to make for a more efficient sequence of use.

The design of RTM asserts that, since text has to be typed for the substance of the task, the UI should attempt to keep the user at the keyboard for as much of the experience as possible.  This can be a huge irritant for new users but incredibly efficient for power users.  It’s hard to say if this is the right or wrong decision since it really boils down to usage.  But as Pete has said before “good software is opinionated”.  The design team at RTM has made a decision about who their target market is and (since I feel I’m part of that group) it really does work well for them (us?).

On the other hand, there are some odd/poor choices in the way the UI provides feedback to the user.  What is that arrow on the first task of each list?  If multi-edit mode is not enabled, why allow the user to select multiple tasks?  Why is task sorting exclusively by priority and date? Why are there no keyboard shortcuts to move tasks from one list to another?

It is tough to write truly useful, inclusive software.  I would be hard pressed to hold up RTM as a shining example of a universally appealing success.  Nevertheless, for my usage scenarios, it does what I need it to do brilliantly.  Like all good software, it lets me do what I want (manage my tasks) and gets out of the way.

Windows 7 on a Dell Mini 9

So I jumped ship off Jaunty yesterday morning with build 7600 (RTM!) of Windows 7.  The install was smooth using a bootable USB drive and isn’t really worth describing in detail here.

In general, nearly everything seems to have worked right off the bat.  Video, sound, network – everything is up and stable.  Immediately I was surprised at how clear the fonts and general rendering are in Win7 (far more clear and precise than in Ubuntu).

A few issues have presented themselves:

• The Synaptics touchpad wasn’t recognized but installing the Vista drivers seemed to do the trick.
• 3 devices are listed as unrecognized in the Device Manager (two “Base System Devices” and one “Unknown device”). Good to see that the help on getting devices working has improved since Win95… :(  This doesn’t seem to have any meaningful impact but I’ll update if/when I figure out what they are.
• I’ve been reading a lot about how fast Win7’s boot times would be but that hasn’t played out.  Where Ubuntu was loading in sub-30 seconds Win7 is at least double that. Interestingly, it does appear that the boot up process is freezing just before showing the login screen but there is nothing in the event log to explain this.
• While Sleep mode generally works, in one case this morning it caused the computer to reboot.  The event viewer – as informative as always – says there was an “unexpected system shutdown”.  Thanks.

What I’ll miss from Ubuntu:

• Gnome Do: a simple, clean application that just helps you do things and gets out of the way.
• Tomboy: absolutely fantastic for taking notes in meetings (which is the primary use of my netbook). I’m switching to OneNote for now but I miss it already.
• Ubuntu Netbook Remix: it really was a nice metaphor for dealing with a cramped space and small screen.  Maximus in particular.  Win7 can be customised to use as much of the screen as possible so it will be interesting to see how this plays out.
• Snappiness.  This isn’t exactly a fair comparison since I’m running Win7 with all of the Aero on.  Of course, if I wasn’t running the Aero chrome I’d be using WinXP so maybe it is fair.  Either way, Ubuntu seemed to just zip along a little more smoothly than Win7 which tends to freeze and hiccup.
• Nerd factor: there’s something that just gets me juiced about Linux.  Win7 is pretty new and running it pre-RTM release date tweaks my inner geek enough to make this worthwhile.

On the other hand, being back in the warm embrace of Windows does carry some benefit.  A simple example is being able to run Firefox 3.5.  It’s been weeks since it was released and it still isn’t available through the core repositories for Ubuntu.  Yes, I know I could hack it in but why the hell should I have to?

Windows Media Player is another thing I’m happy about. I’m not a big fan of it one way or the other but frankly, it just works.  I can play music off my file server.  I don’t have to open configuration files in VI.  Thanks but that’s good enough for me.

Finally, I certainly won’t miss the constant stream of update patches that had unintended consequences without any supporting documentation (support for 802.1X, I’m looking at you).  You can fault Microsoft for many things but their patch release management and documentation is absolutely top notch.

Anyhow, so here we are back in Windows.  I still need to find some webcam software but otherwise I should now be into stable daily use.  I’ll write some further thoughts as I get the chance to test this over the long term going forward.

Wild-Caught Perch in Parmesan Breadcrumbs

Wild Caught Perch in Parmesan Breadcrumbs
Originally uploaded by The Cooking Coder

This was a super easy appetizer that I put together to get our engines going on a nice Friday evening meal. I got the Lake Erie perch from the Healthy Butcher and put it in a breadcrumb mix with grated parmesan and fresh oregano from the garden.

It's then fried up in a little bit of butter and olive oil to keep it simple. It's garnished with a stripe of sriracha Thai hot sauce and fresh chives. Simply fantastic! :)

Reminiscing about Software Engineering

Jeff Atwood’s recent blog post about why software developers hate software more than anyone else is a great read.  It’s even funnier for me since his example of installing digital camera software is the exact same thing I experienced with my new camera a few weeks ago.

Interestingly he links to an interview with David Parnas from 1999 and quotes the following:

What is the most often-overlooked risk in software engineering?
Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

What I find interesting is that Dr. Parnas was the Director of the Software Engineering program of which I was in the first graduating class.  In the 12 years since I made the decision to opt for software engineering over computer engineering I’ve given a lot of thought to what I was taught in my 4 years at McMaster.  Reading this quote brought a lot of those thoughts back up to the surface:

What are you doing now?
We've started a new Software Engineering program that I think is the first real SE programme in the world. It is an undergraduate program treated just like the other undergraduate programs in engineering. It is designed to get people licensed by the Professional Engineers and I agreed to direct it while it was getting started.

The trouble with teaching the first software engineering programs is that you don't have any software engineers to teach them. There is a bootstrapping problem because there are no graduates yet. Today's programmers may call themselves "Software Engineer," but most do not have the right to call themselves "Engineer." Most do not know what we expect our graduates to know. The best programmers are self-taught. We very much need Engineers who understand software but they are very hard to find.

Ours is the first software engineering program that wasn't started in a computer science department or in computer engineering. The concept of this department is based on an intriguing idea: consider the meaning of the phrase "software engineering." If you look at the history of engineering, you can see that over the years, different branches have split off from engineering, introducing disciplines such as mechanical, civil, electrical, chemical engineering. As our knowledge of science and mathematics grew, it was no longer possible to teach every engineer all that we knew. We were forced to identify various disciplines within Engineering.

At McMaster, we regard software engineering in the same way. There is a great deal that I believe all engineers should know about software but we only have four years to teach them. We decided to address the problem by treating Software Engineering exactly as we treat Chemical Engineering. That way of thinking leads to a program that looks very different than a conventional computer science program. The conventional program considers software engineering to be a specialty of computer science with a few more courses in software. We view Software Engineering as a specialty within engineering. Our students take most of the standard engineering course. There are 42 required technical courses of which about 19 deal with "core" engineering material and the rest are specialized material that is needed for software engineering. This includes some CS material and a lot of mathematics as well as software design courses that include projects. It is important to understand that this is education, not training. We teach fundamentals throughout. None of our courses center on current products or languages but we use practical tools in the many laboratory experiences that are part of the courses.

I was and continue to be proud that I was educated as an engineer first and a software specialist second.  Nevertheless, the program did have a certain learning-on-the-fly quality to it that I felt left me very unprepared when I graduated.  By its nature I left university with what felt like an incomplete skillset.  What does rigorous software specification have to do with building enterprise-class software?  How does tautological logic help me to sell my product?

To expect any school program to prepare all of its students to be ready to hit the ground running in industry is obviously unfair.  There is, however, an obvious tension that is created when you release “real” software engineers out into a marketplace where their skills are not necessarily valued nor are they demonstrably better at the craft of writing software.  This is especially troubling when taken in the context of Tom DeMarco’s recent writings.  Is software engineering dead?  Was it ever alive to begin with?

This isn’t going to be answered anytime quickly.  I do still believe that there are elements of this business that fall squarely in the realm of engineering.  Alternatively, there is an art to software that is very real.  It is this creative side that separates the journeymen from the truly great programmers.  To some degree it is a passion for the craft – a passion to learn more and to solve harder and harder problems.  It reflects a natural aptitude that some programmers possess and others do not.

So am I happy to have been trained as one of the first software engineers?  Absolutely.  Did my education lead to what has – to his point – been a successful career?  Probably.  Is engineering the road that all great (or even competent) programmers must follow?  Probably not.

Possibly the Best Pea Soup

I haven't actually had the chance to try this recipe as yet but it certainly sounds good. I'll update when I do (hopefully this weekend!).

Creamy Sausage Orecchiette with Garlic Scapes and Summer Peas

Creamy Sausage Orecchiette with
Garlic Scapes and Summer Peas

I had the chance to put together a nice improv meal on Friday by basically raiding the fridge. Here's what I cooked up (the quantities are approximate, to say the least):

Ingredients

• 1/2 kg hot Italian sausage
• 1 pint of fresh peas, shelled
  
• 5 garlic scapes, chopped finely
  
• 1 onion, diced
  
• 1 cup of cream
• 1 cup of parmesan cheese, grated
  
• Handful of fresh parsley, chopped roughly
  
• Salt & pepper to taste
• 500g orecchiette pasta
  

Prep

1. Take the casings off the sausage and brown them in a deep pan. Remove and reserve.
2. Throw in the onions and sweat them for a few minutes followed by the garlic scapes. Once they've softened throw the sausage back in and mix it up.
   
3. Add the peas and cheese and allow it to melt. Stir in the cream and cook it on low then season to taste.
4. Hopefully by now you've got your pasta ready, if not, travel back in time until step (0), boil water, make pasta, etc.
5. Mix the pasta and the cream sauce, garnish with the parsley and serve.

One final note, I'm pretty thrilled with the garlic scapes that Karen picked up at the Liberty Market last weekend. They've been delicious in pretty much everything I've used them in. Between the Liberty and the St. Andrew's Markets it's great being able to access to fresh produce every weekend.

The Complimentarity Between Cities and Skills

Interesting article [PDF] on the concentration of skills and knowledge in big cities.  The abstract:

There is a strong connection between per worker productivity and metropolitan area population, which is commonly interpreted as evidence for the existence of agglomeration economies. This correlation is particularly strong in cities with higher levels of skill and virtually non-existent in less skilled metropolitan areas. This fact is particularly compatible with the view that urban density is important because proximity spreads knowledge, which either makes workers more skilled or entrepreneurs more productive. Bigger cities certainly attract more skilled workers, and there is some evidence suggesting that human capital accumulates more quickly in urban areas.