brainsnorkel.com

This week I installed Ubuntu 8.04 LTS on my Vista desktop using Wubi. Wubi lets you install Ubuntu as a dual-boot option that can be uninstalled from Vista’s add/remove programs control panel widget (but why would you?).

Short review: Wubi Rocks.

For a long time I thought that if I were better able to quickly construct illuminating diagrams to make a point or communicate a concept then I’d be a much more effective communicator. Effective communication is a boon to software development, so improving my ability to rapidly pump out neat diagrams was a noble goal worthy of investment.

I thought that if I had a tablet I’d be able to pick up any drawing package and quickly render those few boxes, circles, arrows, classes, use-cases and swimlanes with a pen in double-quick time. Surely a pen is the natural way to draw, and therefore faster and easier.

I had my eye on a Wacom tablet for a while. I had used a few casually and found them awkward. Designer friends told me that it takes some getting used to and a rigour about the way you set up and use applications. I had also worked with a UK-based engineer who used one for illustrating and annotating shared applications, presentations and documents during design collaboration conference calls. I was convinced my first impressions were wrong.

“Cool” I thought. “Let the tablet-led communication-effectiveness and R&D begin!”

After I saw that Julian had a tablet, I abandoned rational thought and cool-headed evaluation while toy envy took over. I dropped about AU$100 on a cheap Wacom-like tablet to figure out if it was a worthwhile addition to my professional and home-tinkering life.

After getting used to looking at the screen and not the tablet, and making the mental switch from mouse-relative pointing to tablet-absolute positioning seem relatively natural I worked on using a few applications.

In a week or so of trial use I came to the following conclusions:

• EverNote is way cool for doing shape-drawing, but I was still about half as fast at constructing diagrams with the tablet as using a mouse and keyboard. I also made lots of mistakes with the tablet that were kind of painful to correct. I wish more applications had EverNote’s (and the Apple Newton’s) shape recognition/fixup mode.
• Visio is kind of awkward with a mouse, and even more awkward with a pen.
• Few applications have big enough icons that can also be positioned conveniently enough for tablet use.
• Unsurprisingly, the best applications are painting programs like Photoshop and Paint Shop Pro. Primarily it’s because with a tablet the curve you render on the tablet is the curve you see on the screen. With a mouse, you have to convince your body to implement a kind of feedback and control system to modify your physical action to produce the curve you want to render.
• Tablets are cruel and frustrating.

I gave up on the Wacom-style tablet, though I’m not sure that I gave it a fighting chance. I got to a point where my frustration was greater than the residual value of my AU$100 investment and abandoned it.

Time passed… and the opportunity to get a tablet PC at less than extortionate prices presented itself. Quite apart from the X61 being a tablet PC, it’s far more portable and usable than any laptop I’ve owned since my Mac PowerBook 170.

In summary, in the contest between tablets and tablet PCs, tablet PCs win.

Direct manipulation of screen pixels is much more approachable than separate tablet hardware. They’re more portable, convenient for more applications and they don’t get your colleagues confused about whether you’re a graphic designer or a developer.

That’s not to say tablet PCs are the perfect tool for diagramming.

Bear with me while I offer some completely un-benchmarked productivity estimates.

When it comes to drawing diagrams with perfect boxes and lines in an application like Illustrator or Visio, I’m about 20% faster with a mouse. If the requirement is for nicely typed text, then the mouse and keyboard wins by about 50% over the tablet PC.

But there’s a diagramming mode where the tablet PC shines: freehand diagrams.

If the boxes, lines and arrows don’t need to be perfect, and if the text is handwritten, and if the diagram won’t need to be maintained, then drawing freehand using OneNote or EverNote on the tablet PC is probably 50% faster than using a keyboard and mouse.

After recognising this my primary use of the pen mode on my X61 Tablet has settled into these tasks:

• Quick and dirty diagrams to capture notes or communicate information, often projected on a meeting room display or web conference, and sometimes to be later transcribed into a “proper” UML tool or Visio.
• Annotation of documents, spreadsheets and presentations with Office 2007’s pen reviews.
• Note-taking & annotation of typed notes.
• Painting.

For me personally, the dream of being able to use any illustration package more effectively with some kind of tablet is gone, yet note-taking with freehand illustrations is something I now find indispensable.

Every patch on my X61 tablet seems to bring Vista closer to the nimble responsive OS I’d like on my quasi-mobile PC that isn’t a Mac.  Today I noted on (Ars Technica) that Vista patch nirvana had arrived: SP1.

It’s not kidding either.  It was 1 hour and 20 minutes later that it declared Windows Vista SP1 installed on my tablet.  Thankfully no intervention is required during that time.

Now fingers crossed that not waiting for the Windows Update push in mid-April will spare me an NT 4.0 service-pack-like experience. 

So far I can report an overwhelming sense of sameness.  It’s quiet.  Too quiet.

Update:…and it boots and comes out of sleep faster.

Once upon a time in 2002 or 2003, Mr Ed asked me if I had any interest in writing an essay for a new web site he was thinking of setting up called HackNot!  I had a bunch of mostly sardonic and simple thoughts in a file somewhere and I sent it off to him asking if this was the kind of thing he was after.  He relied yes, and I duly got busy with something else and evaded towards completing it. 

I think Ed grew tired of waiting for me and edited my incoherent rambling into an ordered list and plugged it up into public view. 

I thought that now, nearly 5 years later, would be a good time to re-examine some of those thoughts.  I’m way kindler, way gentler, and way more verbose now.  The process of looking at what I thought 5 years ago is bound to ignite a flame war with myself.

I’ve taken a copy of the HackNot! article and added notes along the way.

In 1995 the Unabomber’s manifesto was published in The New York Times. In 2001 the Agile Alliance published their Agile Manifesto. Now our own Tedious Soporific gets in on the act. His personal manifesto leaves no area of software development untouched - from the hazards of frameworks to the role of “doof doof” music in requirements elicitation, it’s all here. Truly a heartbreaking work of staggering genius.

Heartbreaking and staggering but not genius.

Requirements

• Humans read requirements.
• Humans lose interest if they can’t understand the requirement, or why it’s there.
• Requirements numbers should never contain the section number of the document they are in.
• A requirement only needs to require an implementation in rare circumstances when you need to require a point of concrete integration(shall run inside IE 4.0 and up etc.)
• Requirements should be able to be tested. If you write a requirement that may be hard to test, write supporting notes about how you would envisage the requirement will be tested.

This is a bit of a crude list of things that have irked me about requirements in the past.  I would say, without fail, that poorly written, or conceived, requirements cause me the most pain in my work.  Both reading other peoples’ and re-reading my own hastily-prepared requirements can be a trial.  These days I think I would just point to Carl Weigers’ two excellent texts and leave it at that.

According to Capers-Jones, best practice is to spend 10% of a “systems” software development project’s effort on systems engineering.

• User interfaces are design, not requirements.
• Track requirements met during development by mapping requirement coverage to test results.

I stand by my statement, but the reason it’s a manifesto entry is that UI design is not a requirements generation activity.  It’s a design activity, and a vitally important one.

One of the most interesting diagrams about the importance of user interface design and its relationship to estimation I’ve seen is on page 39 of Steve McConnell’s “Software Estimation: Demystifying the Black Art” (see a spreadsheet I prepared earlier here) where he discusses the cone of uncertainty.  This diagram is about the variability in estimates done as a project progresses. 

Before “product definition” a project may take from one quarter to four times the time estimated at this point.  Estimations done at the time detailed requirements are available take the likely variability ranges from two thirds to one and a half times estimates done at this time.  The next step is user interface design.  When the UI is designed, the likely variation from estimates done at this time are from 0.8x the estimate to 1.25x.  If you’re not doing a UI design and re-estimating at each milestone of project definition, you’re not interested in estimates.

I’d go further than tracking requirements to tests and say that requirements should be mapped to architecture and design so the relationship between design decisions and requirements is obvious to developers and archaeologists who look upon your project in later years. 

• Because a customer asks for a feature to be implemented, that alone doesn’t make it a good feature.
• Moral time: A man walks into a hospital having already diagnosed himself with prostate cancer. He demands that a surgeon operate immediately to remove the cancer. The surgeon operates. The man is caused inconvenience, discomfort and pain for the rest of his life from side-effects of the operation. The surgeon could have refused to operate, citing that 80% of men die with, and not because of, prostate cancer. The surgeon gave the man what he asked for and not what he needed.

What a smarmy bastard I was.

A simpler way of putting this is that the job of a software professional is to tell your customer when they’re asking you to do something they shouldn’t do.  Sure, they can go ahead and do whatever the silly thing is anyway, but you shouldn’t really let someone demand that your team build a content management system when there are free and commercial versions out there that may meet your customers’ needs.  Customers tend to talk about how the system should look, so it’s easy to fall down a rabbit-hole of having the customer design everything for you.  If you are mindlessly implementing everything your customer tells you to, you’re somewhere in the spectrum of working with a very capable customer to not behaving as a professional software developer.

• Q: What can you brush your teeth with, sit on, and telephone people with?
  A: A toothbrush, a chair and a telephone.

This is a bit too subtle and clever, which contradicts something else in the manifesto (see below).  I advocate looking at the problem to see if you’re solving one problem or several.  Consider if it’s really appropriate to solve two or three distinct problems with one development or a monolithic product.  Any way a project can be made smaller, or divided up into several projects is advantageous.  In software we have know from Barry Boehm’s work that there is a diseconomy of scale of software development, so three small projects have a much greater chance of succeeding and coming in near to time than one big project does.

Performance

• Specify performance early.
• Optimise late.

Specify performance requirements as early as you can and realistically.  If you find your customer pulling very ambitious figures out of thin air, mark the performance requirement for later.  If you find there is hard and believable data behind the performance requirement, then you should note the source and breathe easy that the performance requirement is believable.

Optimising late is a reaction to developers who get carried away making code perfect up front.  If you have a believable performance requirement that is unprecedented then you should see this as a project risk and consider prototyping, benchmarking and discovering early if your project needs to be sent to an early grave for being infeasible before you spend a lot of money and reputation on something impossible.  Pay attention to performance and don’t optimize things that aren’t a bottleneck or won’t help you meet your project goals. 

Documentation

• Styles in Microsoft Word are your friend. If you want a Word processor, use Word. If you want a typewriter, use Notepad.

There are many things that may be reused in software development.  Documents are one of the most commonly reused development artifacts.  If you use Word to do your documentation, learn about styles, automation, cross-references, footnotes, and keep your source material close to the document and in source control.  Don’t be too proud to go on a Word course - if you’re tabbing, or double-entering to get paragraph markers please go on a course. 

Design

• Beware the “framework.”

Perhaps this should read “Beware the project with no end and no clear customer” as this entry was about projects that allow themselves the luxury to think that everyone wants what they’re producing they just don’t know it yet.  I’m sure many successful frameworks came from over-resourced projects with an ambition to meet requirements they just invented for customers that “don’t even exist yet” but I’m also sure there’s a 20:1 ratio of failures to modestly successful frameworks born from over-generous budget allocation.

• Spurn the “reusable component.”

Reuse was big at the end of the 90’s, resurfaced as Product Line Engineering in the early 00’s and seems to have died down prior to resurfacing as SOA around about now.  I’ve written before about how I think that design, experience and plain-old code-stealing are some of the most effective forms of reuse.  Backed by tools that support findability and developer communication, code reuse will blossom in an organization.  Building a repository of carefully curated reusable components and controlling their use and limiting their mutations is intended to reduce testing requirements and defect propagation, but it also stifles innovation and discourages reuse.

• It’s hard to specify a framework because what users might require rarely becomes what they’ll need for sure: “You ain’t gonna need it.” Your customer wants to pay for a solution for their problem, not everyone else’s.

Would you like to be a customer who wanted to pay for an SQL query and got an ORM framework for only twice the price?

Technologies

• XML: it’s just a verbose way of representing structured data.
• SIP: it’s just a signalling protocol.

The road to hell is paved with overreaching hyperbole about the potential of new technologies.  Both XML and SIP are useful technologies; both brilliant and compromised.  Before them was WAP, Token-Ring, OpenDoc and a lot of other promising technology that was way over-hyped. 

Projects

• Top Ten Lessons from the Dot Com Meltdown
• Try not to build R2 before R1 has any customers.

Most projects have version two of a product loaded up with features a long time before version 1.0 has been seen by customers.  The absolute best resource for requirements is customers, and their best ideas don’t come in focus groups or interviews about the problems they have.  Customers’ best ideas come when they’ve seen version 1.0 and hate it enough to tell you what they’d really like.  If the next release is already full of requirements that are sourced from marketing or product management, customers will be upset with 2.0 as well.  If you can’t make them happy with release 1.0, make them happy the second time they see a release.  Customers you listen to become your ally and make marketing a whole lot easier.

• When someone says “I know this is a death march, but you will be rewarded well if you succeed or fail,” run (away) like the wind.

This was a lie told to me once.  Use the experience to remain as professional as you can, or run.

Peopleware

• Habitable development environments.

This was a placeholder for something I read once and could never find again.  The idea is that, like share accommodation, teams need to find their level of process and code hygiene.  Some brilliant developers work with little infrastructure and formality and others work best with lots of structure.  When building a team consider what each developer finds habitable and make sure you get a team that can accept the coding standards, process rigour and meeting load that you intend to inflict on them.  In a share house, some people like to leave the dishes until there’s a good pile, others like to wash everything on a regular basis.  If you have lived with people at either end of the cleanliness and habitability spectrum, you know how important this can be.

• Give directives in positive terms.
• Avoid saying what shouldn’t be done.
• Toddlers and software engineers want to please you, and do the right thing.
• Toddlers and software engineers hear “Don’t do X” and become paralysed with uncertainty because they now know for sure what they shouldn’t do,but can’t figure out what you do want them to do.

How patronising!  It’s a subtle message. 

If you want people to change, tell them what the outcome should look like in terms they understand.  If an executive stands up and says “don’t be evil,” your expectation is that you can go right up to the line, lean over and smell the sulphur, and still be in the clear.  If your executive says “from now on we’re not a services company” middle management might set about firing your services staff with no vision for what you really want to be. 

User Interfaces

• Usable interfaces should not be innovative. If it’s clever or tricky,then it’s probably confusing.
• Users don’t use the right mouse button.

Let’s back off to saying that you can’t expect users to rely on the right mouse button.  Watch some regular users use applications sometime. 

• It’s hard to know when to double-click unless someone shows you.

Watch some users sometime.  A lot of older users double-click hyperlinks because someone once showed them that the way you get a computer to respond to you was to double-click.

• Users don’t use tree views. Users don’t get trees.
• Users only (very) rarely see trees on computers.
• Developers love tree-views.
• DevStudio [and Eclipse have] trees.
• Windows file explorer shows a tree.
• Most users never see or use tree-views when they’re using Windows (or Macs) and don’t find them comfortable.
• Think about where the Windows explorer is located in the Start-> menu(it’s an “Accessory”) and where the “My Computer” icon is (on theDesktop) and what happens when you double-click it.
• You have to configure Outlook to show a tree view of your folders on the left.
• Standard Windows application file (save/open) dialog does not show a tree.
• A tree is not an easy metaphor. When was the last time you saw a real live tree of folders?

I guess I was tired of seeing lots of new applications that looked just like the IDEs used to build them.  The tree has thankfully been supplanted by the Google-like search & results list. 

Miscellaneous

• It’s hard to write requirements unless you’re ears are being pounded by”doof doof” music.

Actually “doof doof, chikka, doof doof” music is better, I’ve found.

• Unfinished Sympathy is the finest pop song ever written.

I have to revise this one day.  But the combination of serious-sounding nonsense lyrics, orchestral pomp and an addicting hook make it hard to beat.

• “Refactoring” is not synonymous with “fixing bugs”.

Like the XML and SIP thing, this was written at a time when the term was overused.  “I’m going to refactor that bug report” or “I’m going to refactor my performance problems” were not uncommon.

I’ll follow up later with “Epiphanies about software” posts, but I think I’m done with manifestos.

Today I updated my iTunes software to version 7.6 on Windows XP and Vista, hoping to see if I could rent “300″ and play it, and get an idea of whether I liked the whole rental idea. Sadly, though I can play music fine, iTunes 7.6 doesn’t want to play audio from my TV Shows or Movies anymore.

This “no sound” experience happens on both my Vista and XP machines.

US$3.99 down the drain, and only 30 days left to rescue my movie hire.

I’m baffled. One more gripe to add to the list.

I’ve been using Windows Live Writer for the last couple of posts.  If you’re looking for WYSIWYG editing on WordPress, I can recommend it. 

Live Writer grocks your site’s styles (I doubt it can handle coded style extensions, though) so you can get a pretty accurate preview before you post.  It automatically handles image uploads, categories, gives you buttons to access the dashboard and comments management and produces pretty spare markup.  I haven’t used the video options or any of the other options, but I can acknowledge they’re there. 

It even allows me to gratuitously show off my new toy with…

In all, Live Writer has proven to be a very pleasant offline blog editor.  Between OneNote and Live Writer, I’m in danger of becoming a Microsoft fanboy!

At US$25 you can’t go wrong with Art Rage. 

How much is Painter again?

Sure, my images are crappy, childish and abstract… but that’s so very me!  Just wait until I get into my cubist period.  In my defense, these pictures were just thrown together for this post to show a little of what’s possible.

My kids seem to sense when I’m using it.  It’s very hard to get time alone with the new computer when Art Rage is loaded.

If you’re at all interested in Green Computing, can I commend the proceedings of GreenCom07. There are some excellent papers that should be good reading for anyone who’s interested in data centres, power and heat-aware software design, hardware architectures or saving the planet one CPU cycle at a time.

You can also play “pick the odd person out” when you review the Program Committee.

I had a need to convert from (unprotected) WMA to MP3 on the weekend so I could edit together a family podcast — something that previous generations might have called an episode of a very amateurish radio show.

I thought I might have to buy something like Microsoft’s mostly harmless and unnecessarily expensive Plus Pack, or use a scary-looking utility from a scary-looking downloads site. After trolling the Internet for utilities and advice I was almost resigned to taking the scary utility option. About the only place I trust that turned up on searches was Audacity’s site, which simply says that WMA is a patent minefield it doesn’t want to play in.

The answer that didn’t turn up anywhere near the top of the search results that should have was iTunes. In iTunes’ preferences, set the “Importing” tab’s encoder to give the output format you desire, and set sub-options to match your taste. Dragging WMA files into your iTunes library now converts them to the format you’ve configured. Just remember to set that format back to something sensible if you’re going to rip a CD.

Hail Eris. Hail Jamms. Hail KLF. Hail almighty C’thulhu and Bruce Schneier’s thing about squid.

Oops. This is supposed to be a post written in homage to Password Safe (home). I’m probably the last person on earth to find out about password Safe, and that was quite some time ago.

Password Safe is an essential part of every computer user’s arsenal of utilities. Password Safe is a utility for securing all of your passwords in a database file encrypted with the Twofish algorithm. This means you can generate crazy and hard to guess passwords for every site, and have a chance of remembering them. You can store all of your different login information in one place instead of using the same password for every one and hoping no unethical site thinks to try your userid and password out on other sites. In fact, any private information you want to keep secret can be entrusted to Password Safe. The difficulty with non userid/password information is figuring out what to name it so you can find it again easily.

You can install Password Safe everywhere you go, or run it from a USB flash dive. If you run multiple instances of Password Safe with multiple databases get a Gmail, Amazon S3 or similar account and mail/transfer yourself your password safe database occasionally even if you have a USB drive. I use Password Safe to merge changes from my emailed databases to my other Password Safe-running computers.

The risk to carefully consider is that your password database is protected by a single “safe combination” (password). Don’t forget it. To practically protect your other passwords you need to remember a single strong password like, say, some hash of Sissy Spacek and/or Steve Martin’s character names in The Man With Two Brains and never forget it. If you’re writing a will, you might want to include a treasure map to the place you buried your Password Safe combination or drop a cryptic email to Dan Brown. Or you could advise your heirs to wait until cracking Twofish is trivial with contemporary computer technology.

I have a soft spot for Grady Booch. We knew back in 1993 that he was a hippy, what with all those dotty clouds. Today (you ca see below) he’s still a hippy! A greying, post-heart-surgery, eminent software development guru hippy with a penchant for Halo. It’s a good thing Jacobsen and Rumbaugh set him on the straight and rectangular when they U-ed their respective MLs.

Below is a video embed (courtesy of the YUI Theater) of Grady giving a version of his Turing Lecture “The Promise, the Limits, the Beauty of Software” to an audience at Yahoo!

It’s a heavy sprinkling of software history and a boat-load of personal anecdotes. The anecdotes are especially valuable, as they’re from the perspective of someone who has incredible access to many of the major software development projects and organizations around the world.

It’s jam-packed with golden nuggets of wisdom and fore-warning. Around 8 minutes in he warns about perpetuating organizational silos with (what I’d call) interior-decorator SOA. At 36 minutes he talks about assessing an organization’s maturity through their release frequencies, the presence of a “culture of patterns” and a system or organization. He moves on to Boehm and COCOMO, and the observation that complexity is the dominant determinant of project cost — bad process is something that amplifies the effect of complexity and good process dampens it.

In all, it’s a nice introduction to the how and why of software development and how we got to where we are today.

I’m a bit of a tinkerer in my leisure time. I like messing around with different software, hardware and writing little programs to try stuff out and keep current with a variety of fun-looking technologies. I also do a little bit of development for friends and family, but mostly this is fun-driven as well. This makes me someone who knows jack about most trades and a master of not so many.

My modus operandi is to prepare list of things to do, and then work through them in an order prioritized by fun and tempered by expense.

It’s like I’ve been running my home leisure time as a consultancy practice with myself as my biggest customer. Although I find tinkering endlessly enjoyable I rarely end up with a finished product because I’m more into the journey than the destination. I’ve been thinking about how much more satisfying tinkering would be if it occasionally resulted in something that was more like the dictionary definition of completion. My inspiration has been a recent post by Marc Andreessen on personal productivity, and a recent re-reading of the PSP and TSP management frameworks.

I remember reading that the most important thing about a consultancy practice (apart from customers) is to have a “pitch-able” methodology and a knowledge base. Inspired by this, I thought I’d create a list of things I think I need to develop a sufficiently documented, scrutinized, and understood “home tinkering” methodology with an emphasis on achieving a collection of finished products. I never thought I’d yearn for efficient leisure time, but there it is, I do.

Getting my home tinkering consultancy practice outlined should help crystallize my random thoughts into more consistent processes than I have now. It also opens it up for improvement through helpful suggestions.

My list of areas to discuss, document and make consistent is currently:

• Tasks and To-dos
• Documentation
• Package, Test, Deploy
• Source configuration management
• Password Management
• Data Backup

Over time I’ll write a page on each.