PragPub 2010-06: Issue #12

Table of Contents

Features

- Agile Microsoft
by Jonathan McCracken
Microsoft’s Model-View-Controller web presentation framework is being called “Rails for .NET.”

- Why ASP.NET MVC?
by Michael Swaine
We chat with the Project Manager for the ASP.NET MVC project at Microsoft.

- The Mikado Method
by Ola Ellnestam, Daniel Brolund
The Mikado Method can help you find the troubling dependencies that affect any large refactoring.

- When Did That Happen?
by Dan Wohlbruck
Every electronic computer ever built—and the languages that direct them—trace their roots to Alan Turing.

- Better Tools and Training
by Brian Tarbox
Our current set of static analysis tools is working on the wrong level.

- The Indispensable Developer
by Jonathan T. Rasmusson
Jonathan takes a break from writing The Agile Samurai to share the four things that will make you indispensable.

Departments

- Up Front
by Michael Swaine
Can Microsoft do Agile? Is Pick-Up-Sticks a good model for refactoring? These and other curious questions answered.

- Choice Bits
A little knowledge that is perfectly safe.

- The Working Geek
by Andy Lester
How to Get Fired Correctly: You can’t stop the blade, but maybe you can stanch the bleeding.

- Swaine’s World
by Michael Swaine
Does multitasking battle with our ability to turn repetitive tasks into habits?

- The Quiz
by Michael Swaine
A monthly diversion at least peripherally related to programming.

- Calendar
Author sightings, partner events, and other notable happenings.

- Shady Illuminations
by John Shade
John ponders HP’s decision to buy Palm, but reaches few solid conclusions.

Except where otherwise indicated, entire contents copyright © 2010 The Pragmatic Programmers.

Feel free to distribute this magazine (in whole, and for free) to anyone you want. However, you may not sell this magazine or its content, nor extract and use more than a paragraph of content in some other publication without our permission.

Published monthly in PDF, mobi, and epub formats by The Pragmatic Programmers, LLC, Dallas, TX, and Raleigh, NC. E-Mail support@pragprog.com, phone +1-800-699-7764. The editor is Michael Swaine (mailto:michael@pragprog.com). Visit us at http://pragprog.com

ISSN: 1948-3562

Up Front

Microsoft and Mikado
by Michael Swaine
Agile Microsoft? Really?

To some developers, Microsoft’s technologies are a given, the river they swim in. To others, not using Microsoft’s tools is the default. PragPub being an open source– and Agile–friendly kind of magazine, we tend to connect with the latter group.

So when we get an article titled “Agile Microsoft,” we are naturally intrigued. And we think you’ll also be intrigued by Jonathan McCracken’s introduction to ASP.NET MVC, a framework that some have called “Rails for .NET.”

And there’s plenty more good stuff in this issue.

Have you ever described a software project you were working on as “a house of cards?” Get a little careless with one addition and the whole structure comes crashing down, right? Or have you ever, while working on some legacy code project, felt like you were playing the game Operation, where one sloppy move leads to disaster?

Ola Ellnestam and Daniel Brolund have another game-originated metaphor for this touchiness of complex software projects: the game of Pick Up Sticks, also known as Mikado. The trick to that game is identifying the next stick you can pick up without disturbing any of the other sticks. Ola and Daniel present an approach to refactoring based on that game. They call it the Mikado Method.

It’s an eclectic issue of PragPub. We have essays by Jonathan Rasmusson and Brian Tarbox on how to make yourself indispensable as a developer and the desirability of developer internships, respectively. And Dan Wohlbruck celebrates Alan Turing’s birthday with an essay on his contributions.

Plus, then there’s Andy Lester writing about what to do when you get fired, me dissing multitasking, John Shade getting lost in the HP Way, our events calendar, a quiz, and a selection of prime tweets.

Choice Bits

We Thought You Might Like to Know...

A few selected sips from the Twitter stream.

What’s Hot

Top-Ten lists are passé—ours goes to 11. These are the top titles that folks are interested in currently, along with their rank from last month. This is based solely on direct sales from our online store.

1

1

Agile Web Development with Rails

2^

NEW

The Agile Samurai

3v

2

iPad Programming

4^

9

Hello, Android

5^

7

The RSpec Book

6^

NEW

Using JRuby

7v

4

Seven Languages in Seven Weeks

8v

3

Rails Test Prescriptions

9^

10

Agile Web Development with Rails, Third Edition

10^

NEW

Programming Ruby 1.9

11^

NEW

Arduino

Retweeted is the New Slashdotted

An Italian film company is flying to Oregon to interview me this month. A Brazilian magazine has sent me a list of interview questions via email. I’m sure I can’t be that interesting, or I’d be getting more retweets. Here are some comments we thought worthy of retweeting, for one reason or another. —Mike

Simplicity, Productivity, and Other Threats to Our Way of Life

RT @al3x: “The only weapons we have [in programming] are simplicity and convention.” http://bit.ly/98E6VR — @jhooks

Just when programming was threatening to become productive, along came browser incompatibility to save our profession. — @KentBeck

An approach I often take to testing web application performance is similar to how the US Army tested WW2 recruits for syphilis. — @QualityFrog

Man infects himself with computer virus. http://u.nu/6szsa — @GuyKawasaki

While You Were Sleeping

Rails 2.3.6 is out. Because I write tests, my upgrades are going flawlessly. How are yours going? — @bphogan

So apparently Ajax means “uses JavaScript” and HTML5 now means “doesn’t use Flash.” — @simonw

Stephen Fry to judge Guardian Hay festival’s Twitter competition. http://bit.ly/csHIyN — @guardiantech

Nevada bans chicken suits from polling places. — @anamariecox

In case you missed it: Google checks the rear view mirror, sees the competition spinning wheels. http://tnw.to/16DLy — @TheNextWeb

Guy across the street is proclaiming that he’s too much of a CD guy to move to mp3 because CDs “sound better.” There are CD purists? — @geoffreywiseman

Now @pragprog enters viking land – Pomodoro Technique Illustrated will be translated into Swedish. http://wp.me/paY4e-c2 — @staffannoteberg

I really should get around to watching LOST. I've heard it’s a good show. — @HuntHenning

Deep Thoughts

Now that this unnamed decade is almost over, it occurs to me that it should be called the pre-teens. It was about that confusing & awkward. — @noradio

RT @jasonjwwilliams: There are only two hard problems in Comp Sci: 1. Cache invalidation 2. Naming things 3. Off-by-one errors. — @mmazur

Do you have to parallel park a parallel universe? How many tries do I get? — @merlyn

It was satisfying to respond to the salesman's suggestion that I do an exchange with, “That’s not possible as I destroyed it in anger.” — @noradio

In Case You Were Wondering

No, your iPod doesn’t get heavier when you add songs, in case you were wondering: http://ow.ly/1OJ9c — @danfrakes

“Almost all (99.9%) nucleotide bases are exactly the same in all people.” Why can’t we be friends, why can’t we be friends... — @mandosally

“Genetics loads the gun and the environment pulls the trigger.” Good point to remember! Clinical Genomics CE #mla2010 — @mandosally

Pac-Man’s 30th birthday was marred by the sudden deportation of the Super Mario Bros. What were those fools doing in Arizona? — @ConanOBrien

The Venn diagram for elegant JavaScript code and cross-browser DOM scripting is two different circles. — @jeresig

I love ketchup. It’s the only reason I eat fries. — @ericjbruno

Why Not Why?

The “most faved Tweets” of @_why (also known as why the lucky stiff)

Yeah, we follow some odd tweeters, and you can follow us on twitter.

The Working Geek

How to Get Fired Correctly
by Andy Lester
This is your final paycheck, up through today. Security will escort you to your desk to remove your things. There should be boxes there by now for you to use. Your network logins have been disabled. Do you have any questions?

It’s 4:47pm on Thursday, you’re getting ready to go home, and Doug from HR comes to your cube. He says, “I have something important to talk to you about. Please come with me.”  In the HR conference room, your boss, Sarah, is already sitting at the table. On the table is the company policy manual, a printout from the proxy server, a pay envelope with your name on it, and a box of Kleenex in case you cry. Doug’s prepared everything for what’s about to come.

“Have a seat please,” he asks.

Doug starts in, saying, “as you know, Amalgamated Widgets has a strict policy about pornography on company computers. This is policy 17 in the policy handbook, for which you signed a Statement of Agreement on March 3rd, 2008.”  He produces a form with your signature. “Log files from the proxy server indicate that last Wednesday at 9:17 AM you accessed a pornographic website with pornographic images on your computer. This violates company policy and is grounds for dismissal.”

Your mind reels, not knowing what they’re talking about. You look down at the log from the proxy server, and the domain name jogs your memory. You’d clicked on a link in a Slashdot thread, and it directed you to a pop-up hell of porn banners that made you Command-Q Firefox to get rid of it. They wouldn’t fire you for that, would they?

Apparently they would. Doug continues, “Effectively immediately, your employment here is terminated,” handing you the envelope from the table. “This is your final paycheck, up through today. Security will escort you to your desk to remove your things. There should be boxes there by now for you to use. Your network logins have been disabled. Do you have any questions?”

This tale may be an extreme example of career meltdown, made worse by being blindsided, but it’s not far-fetched. No matter the circumstances, getting fired or laid off is traumatic. Planning ahead can make all the difference in how you handle, and come out of, such a scenario.

It Can Happen to You

If you think it can’t happen to you, think again. There is no such thing as job security. In most states, employment is at-will, meaning either the company or employee can terminate the relationship for any reason, or no reason. Every employee is expendable, and can be replaced. If you’ve ever thought, “They can’t fire me because of X,” you’re wrong.

Whether the reason is a layoff, a performance problem, or a bogus reason cooked up because your grandboss doesn’t like you, chances are that at some time in your career, you’re going to get fired or laid off. As you read on, don’t focus on the specifics of the sordid tale of the scenario I presented, but on how to properly handle getting terminated.

The first thing to remember is that at the point where they’ve told you you’re getting fired, you’re fired. There is nothing you can do to stop it from happening. It’s been planned for days, and isn’t taken lightly. If it’s a layoff, it’s been planned for even longer. There is no reversing the course at this point, so don’t make yourself crazy frantically trying to figure out how.

What Not to Do

Back in our story, Doug asked if you have questions, not if you had anything to say in your defense. The following tactics will not help you out, and will only make you look pathetic:

- Legal threats: “You can bet you’ll be hearing from my lawyer.”

- Claiming to be indispensable:  “What are you gonna do on the Yoyodyne project?  You fire me, that project is doomed!”

- Appeals to sympathy: “I can’t afford to get fired! My wife is in the hospital and ...”

- Indignation: “Man, this is bullshit! I clicked on one stupid link and...”

- Blaming others: “IT should have had their filters working right! What, they know to bust me on a porn site, but not filter it?”

- Dramatic accusations: “This is Steve’s doing, isn’t it?  He’s had it in for me since...”

- Appeals to authority: “Sarah, help me out here! You know I’m good for the company!”

- Spite: “I hope this company goes down the toilet, and it probably will if you treat your employees this way!”

It’s not surprising that these might be the first things to come to mind. Consider the feelings you’re probably going through at that point:

- Fear: How will you pay the bills?

- Embarrassment: Especially if you know it’s something you did wrong, or is for poor performance.

- Humiliation: Your co-workers will find out tomorrow morning that you’re “no longer employed by the company.”

- Panic: Trying to figure a way out.

- Anger: The company is throwing you out.

All these feelings are entirely understandable. However, this is no time to act on them. Your emotions will be high, but you need to be calm and professional for the sake of your future career. You can either be remembered well by others, and in the stories that they tell, or you can be the guy who acted like a freak and threatened to call lawyers.

It’s also important, for your own sake, to keep your personal dignity. They’re firing you, but it’s not the end of the world, and it doesn’t mean you’re a terrible person, or a failure at life. People get fired all the time. If it helps, remember that it may have nothing to do with you personally.

What to Do

So what do you do?  Accept what is happening at the time and go through with being fired, and do it with dignity. If you’re getting fired for cause, rather than being laid off, don’t discuss the reasons. Don’t threaten. Don’t explain.

If you’re asked if you have any comments, simply say, “I don’t have anything to say at this time.” If they ask you how you feel, because they’re trying to gauge your reaction, say, “I don’t have anything to say at this time.” If they ask if you understand the reasons for your termination, just say, “I don’t have anything to say at this time.”

Responding with “I don’t have anything to say at this time” leaves your options open. It doesn’t say that you’re OK with what’s happening. It doesn’t say that you agree with the reason they’re firing you. It leaves the door open for a legal challenge if you choose to do that. Most important, it gives you a dignified response.

It’s also important that you keep your options open if they want you to sign papers, especially if you’re fired for cause. Do not sign anything in the heat of getting terminated. Decline politely and say, “I’ll need to review these documents and think about them carefully before signing.”  Take the documents with you, and read them later, preferably the next day. Take them to a lawyer if you’re unsure.

If they make your final paycheck contingent on your signing, say, “I understand, and I’ll get back to you.”  Rest assured that the law is on your side. An employer cannot legally withhold your pay for work you have already done. If they claim the paperwork is “just a formality,” don’t bite. Take them home to be signed later.

Signing anything in that emotional state is never a good idea, and a company may use that fact to its advantage by trying to coerce you into signing something disadvantageous to you. For instance, say you get fired for coming back from lunch smelling like beer. They fire you, and cajole you into signing an “exit form” to get your final paycheck. Turns out that that “exit form” also says that you agree that the company had reason to fire you, and you’ve just signed away a potential wrongful termination suit.

Keep calm, politely decline, and tell them you’ll get back to them. Don’t let them turn their hurry into your hurry. They want to wrap things up while you are stunned. Instead, slow things down in the ways that you can. Buy yourself time to think and to explore your legal options. A hasty decision may bite you later. Be strong and don’t get pressured.

What’s in Your Disaster Planning Kit?

So where do you go after getting fired?  How do you pick up the pieces and move forward?  You need to be prepared for such a scenario. Call it the Working Geek’s Disaster Preparedness Test. Fortunately, it’s useful in good times as well as bad. Tune in next month for details.

If you’re in the Chicago area on June 6th, 2010, I’ll be speaking at Uniforum Chicago on what’s new in Perl 5.10 and 5.12. I hope to see some PragPub readers there!

Andy Lester has developed software for more than twenty years in the business world and on the Web in the open source community. Years of sifting through résumés, interviewing unprepared candidates, and even some unwise career choices of his own spurred him to write his nontraditional book on the new guidelines for tech job hunting. Andy is an active member of the open source community, and lives in the Chicago area. He blogs at theworkinggeek.com, and can be reached by email at andy@theworkinggeek.com. Send the author your feedback or discuss the article in the magazine forum.

Swaine’s World

Multitasking Considered Harmful
by Michael Swaine
Does multitasking battle with our ability to turn repetitive tasks into habits?

The term “thoughtworker” is an oxymoron. Thought and work are incompatible activities. The mission of the thinking part of your brain should be to avoid at all costs anything that looks like work.

Let me rephrase that in more impressive language so that it doesn’t sound so much like some kind of slacker manifesto.

The more mental work your forebrain can offload to your hindbrain, the smarter you get. Your higher brain structures are optimized for higher mental processes, like daydreaming and making up limericks. The lower structures are optimized for drudgery, and they need to keep that stuff down in the mental cellar and not bother your consciousness with it.

Centipedal Motion

The Centipede’s Dilemma is a classic cautionary tale of the danger of over thinking. I first encountered it ages ago in Alan Watts’s The Way of Zen, but it really dates back to 1871 and a poem by a certain Mrs. Edmund Craster:

“The centipede was happy, quite, until the toad in fun said, ‘Pray, which leg goes after which?’ and worked her mind to such a pitch, she lay distracted in the ditch, considering how to run.”

It’s very zen. It’s also almost a limerick.

Anyway, the moral of the story is straightforward: Even for the merely two-legged, walking is a skill best relegated to the unconscious mind. If you think about every step before you take it, you won’t be able to think about anything else—and you won’t walk very well, either. There was a time when you had to think about every step, back when you were learning to walk. But learning to walk is a very different activity from walking, and involves different parts of the brain. Learning any skilled activity is very different from performing that activity once you have learned it. You, having learned this particular skill quite thoroughly many years ago, can now walk effortlessly and unconsciously while letting your conscious mind focus on other, more cerebral things, like making up limericks.

We get steadily better at the totality of our mental activity by continually turning conscious thought processes (like learning to walk) into unconscious habits and reflexes (like walking). Many kinds of activities can be at least partly routinized like this: dancing, swimming, riding a bicycle, typing, playing an instrument, proofreading, debugging, saving the file before you get up from your desk.

Muscle Memory vs. Multitasking

What I’m calling work is anything that can be routinized: repetitive tasks, familiar decisions, and the like. All of that activity can be sent to the basement, and should be. Down there, muscle memory gets a chance to take over and get work done while our conscious minds deal with other things.

Or at least it does when our environment allows it to. Consistency in user interface gestures, keystrokes, and layout is a powerful enabler of this when we’re using our computers. When similar user-interface buttons appear consistently in the same locations, we can transfer the use of these buttons to muscle memory.

Get a bunch of repetitive activities running in your mental basement and you’ve got a productive engine room. Free your mind to focus on a single activity and you can achieve flow.

Flow, being in the zone, whatever you call it, should be your mind’s goal. When you’re in that state, you’re totally focused and performing at your peak. Like Pete Townshend’s Pinball Wizard you “ain’t got no distractions, can’t hear those buzzers and bells.” You become one with the game.

So it’s not just daydreaming and limerick writing. It’s gaming. And that means it’s coding, too, because coding, when you’re in the zone, can absolutely be like playing a video game.

Multitasking is the opposite of all that. Multitasking is perpetual paradigm-breaking. It’s mental work, and it wants to monopolize your higher mental machinery, taking your mind away from the daydreaming your mind wants to do.

Penn & Teller

I recently saw Penn & Teller on stage and one routine by Penn Jillette seems relevant. The routine involves a high-power nail gun loaded with a magazine of nails and blanks in a seemingly random sequence. He claims to have memorized the sequence and demonstrates how confident he is in his ability to recall the sequence: he pumps the gun in rapid fire, either driving nails into a board or shooting blanks against his body.

It’s very dramatic, especially when he pretends to get distracted by trying to do the trick while talking nonstop to the audience. He pauses, seeming uncertain. Did he just fire two successive nails into the board, or three? He decides it must have been three, and puts the gun to his neck and pulls the trigger. Very dramatic.

The interesting thing is, it should be possible to do exactly what he’s claiming to do, if the pattern has been memorized so well it can be relegated to your mental basement. Then you could follow the pattern flawlessly while chatting with the audience.

By multitasking I don’t mean performing a memorized patterned activity while carrying on a conversation. Or walking and chewing gum at the same time—or even walking while writing limericks. I mean trying to do multiple higher-level activities at the same time. Try to do that and you’ll soon feel like your brain is on dial-up.

Which is why you should time-box everything that interrupts you. All your communication activities: checking email and tweets, taking calls, permitting face-to-face or face-to-back-of-head interruptions. Consider turning them into face-to-hand encounters.

But we all know we have to manage those interruptions somehow. What’s intriguing is thinking about how to organize your environment so that it helps rather than hinders such efforts.

In an article titled “Habit Fields,” Jack Cheng, founder of “the largest community-edited tea database on the Web,” makes the case that our desks and chairs and all the furniture and tools that we surround ourselves with store our memories, and more than that, our behavior patterns. He suggests that it can be useful to think of these artifacts as emitting habit fields that constrain and enable our patterns of habituated behavior. Which is not always a good thing:

“Thanks to the computer’s ability to multitask, sometimes these habit fields actually become oriented around the act of switching programs! If you’re conditioned to alternate between different modes of working every few seconds, it’s no wonder you have a tough time staying focused on one thing.”

A Physical Time Box

Which suggests what could turn out to be one of the great benefits of the iPad.

I’m starting to hear and read anecdotes from developers who say they are using their iPads for their email and general web browsing—exactly the kind of activities you want to timebox away from your coding. And I’m pretty sure that these developers aren’t developing software on their iPads. Now push that idea a little further. What if you never checked your email or Twitter on your computer? What if you restricted all that distracting activity to a completely separate device—your iPad? What if your computer became the place you went to totally immerse yourself in your coding?

I know you probably intend for it to work that way, but you know it doesn’t. Your computer has become more a source of distraction than your phone or family. What if you could kick all those distractions off your computer completely, exiling them to your iPad? Wouldn’t you spend a lot more time in the zone? And wouldn’t that be a good thing?

Michael Swaine is the editor of PragPub. Send the author your feedback or discuss the article in the magazine forum.

Agile Microsoft

An Introduction to ASP.NET MVC
by Jonathan McCracken
Microsoft’s Model-View-Controller web presentation framework is being called “Rails for .NET.”

Agile Microsoft?

No, it’s not an oxymoron. Things are changing at Microsoft, and if you haven’t taken a peek at what some of the guys in Redmond are up to recently, now is the right time. This March they released ASP.NET MVC (Model-View-Controller) 2.0—a web presentation framework that finally puts agile priorities at the center of a Microsoft framework—priorities like valuing testability and convention over configuration. On top of that it’s completely open source, so you can feel free to modify it to your heart’s content.

ASP.NET MVC—or, as some Rails developers call it, “Rails for .NET”—responds to the needs of agile web developers by making it easy to do test-driven development. For example, in traditional ASP.NET, you’d have to implement an MVP (Model-View-Presenter) design pattern to test-drive your pages. This isn’t such a big problem for experienced TDDers, but for beginners it was a real challenge to get started. Now in ASP.NET MVC, you can easily test-drive your controllers—right out of the box.

Hello, World!

Let’s take a look at ASP.NET MVC at work. Accessing the URL http://localhost/hello will execute the controller HelloController.cs by convention:

HelloController.cs

public ActionResult Index()

{

ViewData["message"] = "Hello World!";

return View();

}

The default URL creates a request that invokes the Index() action. All controllers have a special hash table called ViewData, which contains information to be displayed in the view. Here we simply pass the age-old “Hello World” using the key message. After we’ve completed this difficult processing, we specify which page we want to render by returning a view using the View() method. Based on another convention, this directs control to a View with the same name as the action—Index.aspx.

Views/Hello/Index.aspx

<html>

<body>

<p> <%= ViewData["message"] %> </p>

</body>

</html>

This view renders the string as it was set in the controller. With ASP.NET MVC views you have full control of the markup. With these five lines of code we get a web page that renders these immortal lines:

Hello World!

The way that ASP.NET MVC matches easy-to-read URLs like http://localhost/hello to controller actions makes it much easier to program on the web—something it has in common with Rails. But I mentioned how simple it is to test ASP.NET MVC, so let’s take a look at the unit test using NUnit for the hello world example. We’ll be testing the HelloController’s Index() action:

HelloControllerTest.cs

[Test]

public void Should_Say_Hello_World()

{

var viewResult = new HelloController().Index();

Assert.That("HelloWorld!", Is.EqualTo(viewResult.ViewData["message"));

}

Here we create a new HomeController and capture the  Index() action’s ActionResult to run our assertion against. We then inspect ViewData’s message key for the expected “Hello World!” string, and the test will now pass. Testing in .NET just got a whole lot easier.

More Rails-like Features

ASP.NET MVC also offers other features that are found in Rails. It has action filters, which can be applied to the controller as a whole or to an individual action:

[Authorize]

public ActionResult SecureWorld()

{

ViewData["message"] = "Secure World!";

return View();

}

The [Authorize] filter stops someone from accessing the action unless they’re authenticated. Otherwise, it will prompt them to log in and then redirect them back once they’ve successfully logged in. ASP.NET MVC comes with loads of these action filters, including ones to help with output caching and error handling. You can also strike out on your own and create customized action filters.

The 2.0 release of ASP.NET MVC now includes UI Scaffolding for prototyping. The scaffolding in ASP.NET MVC, just as in Rails, lets you skip creating a view. Instead, a generic view will take care of displaying pages for things like CRUD operations.

ASP.NET MVC also comes with a decent routing engine that lets you create search engine–friendly URLs. The convention is to have URLs match http://localhost/{controller}/{action}/{id}, where {id} is the unique identifier of the model you’re looking at or editing. You can easily add your own customized routes to make URLs accommodate additional parameters; for example:

Global.asax.cs

routes.MapRoute("DateRoute" ,

"{controller}/{action}/{month}/{day}/{year}/{id}");

The first parameter of MapRoute() is the unique name of the route. The second parameter defines a series of variables that will be matched to the input URL. {controller} and {action} are matched to their respective controller and action. The other variables need to match to the parameters of the action. In this case, the action’s signature would need to be ActionForDateRoute(int month, int day, int year, int id).

Integrating with Other Frameworks

A big win for ASP.NET MVC is how simple it is to extend and integrate with other frameworks. It’s straightforward to tie in dependency injection frameworks, allowing you to make your web application more modular and testable. Also, ASP.NET MVC doesn’t come tied to any persistence framework—in fact it doesn’t come bundled with one at all. While some might find this a weakness, I think of it as a strength, because ASP.NET MVC lets you choose whichever persistence framework works for you and your team—NHibernate, iBatis, LINQ-to-SQL, or even MongoDB. Also, if you like a particular markup syntax like Haml or Velocity, you can replace ASP.NET MVC’s default engine with one of the many open source ones already available, like NHaml or NVelocity.

When it comes to the markup, ASP.NET MVC hands you back full control. Views are rendered with simple HTML helpers instead of messy ASP.NET Web Form Controls. ASP.NET MVC 2.0 has some nice helpers like the EditorFor() method:

Html.EditorFor<Person>(person => person);

This helper method allows you to pass whole objects for editing. The magic of this method is it uses reflection to render the right HTML input controls based on the data type. Its close cousin DisplayFor() does the same, but for read-only screens.

Of course, Microsoft can’t do it all, and MvcContrib, an open source extension, helps fill in some of the gaps. First off, testing your controllers becomes even easier with MvcContrib. We can add another test to our earlier hello world example to check that the correct view is being rendered:

HelloControllerTest.cs

[Test]

public void Hello_Index_Renders_Index_View()

{

var viewResult =  new HelloController().Index();

result.AssertViewRendered().ForView("Index");

}

While this is a somewhat silly test, since we’re checking an ASP.NET MVC convention, it can prove useful as you begin modifying those conventions to render different views based on more complicated scenarios. MvcContrib makes it simple to create REST-style interfaces on top of pages you’re already serving in HTML. MVC Contrib makes it easier to test-drive your application by making tests shorter and more readable. Also, it has a few HTML helpers, like Grid, which makes it simpler to display tabular information.

A bonus in the timing of ASP.NET MVC 2.0 is that Visual Studio 2010 and C# 4.0 have also just been released. C# 4.0 has some nice features like optional parameters that ASP.NET MVC can take advantage of. For example, if you’re creating a new Product model and you don’t want pass the id because there isn’t one yet, optional parameters allow you to leave the id blank without causing a validation error. Also, C# 4.0 now has a dynamic data type, which opens the door to more Rails-like conventions when generating and reusing views. Visual Studio 2010 itself is also slightly faster than its predecessor, an uncommon thing for Microsoft.

All of this adds up to some big wins if you’re writing a .NET web application. If you’ve found yourself on a .NET project and were considering using ASP.NET Web Forms (aka traditional ASP.NET)—hold the phone, and consider ASP.NET MVC instead. It’s also one of the reasons the Pragmatic Bookshelf is giving it some attention in their library with Test-Drive ASP.NET MVC going to print this month.

Jonathan McCracken is the Director of Services with ThoughtWorks Canada. He has developed .NET applications for a wide range of companies, including Microsoft. Jonathan has been developing software since 1994 and his .NET experience goes all the way back to .NET 1.0 in 2002. In addition to his professional activities, Jonathan enjoys speaking and blogging about diverse topics such as technology and the meaning of life. Send the author your feedback or discuss the article in the magazine forum.

Why ASP.NET MVC?

An Interview with Phil Haack of Microsoft
by Michael Swaine
We chat with the Project Manager for the ASP.NET MVC project at Microsoft.

“You should interview Phil Haack,” Jonathan McCracken told me on the day that he turned in his article on ASP.NET MVC for this issue. “He can provide some perspective on the technology.” It seemed like a good idea. So we did.

ms: Thanks for chatting with us, Phil. Could you start by describing your role on the ASP.NET team?

ph: My role on the ASP.NET team is to provide comic relief and to raise a ruckus. As my co-workers often remind me, I’m not that funny. So I guess it’s a good thing that my official role is that of a Program Manager (PM).

ms: Which means—?

ph: The Program Manager role at Microsoft means slightly different things to different teams, but in general PMs focus on the big picture when it comes to a feature or product, making sure we’re building the right features, and then driving the product or feature set to completion.

On the ASP.NET team, we often use the term “ownership,” as in a PM “owns” certain features. Often, this means simply making sure nothing falls through the cracks. My primary focus has been ASP.NET MVC, but I own several other features as well.

ms: What’s your technical background?

ph: Not counting an abacus, my first computer was a TRS-80 Color Computer my dad bought when I was around five or six. That was my first exposure to programming and computers, though much of that was time spent with my dad typing in hundreds of pages of BASIC listings. I remember also writing a lot of stupid little programs at the time. I wrote a Mad Lib-style program as well as a program that was intended to store all my sordid secrets (which admittedly were few). The program required a password, but was easily circumvented by a command to list the source code. It was many years before I learned about such things as encryption and hashing algorithms.

That experience started a lifelong love for computers, though I didn’t start programming professionally until I graduated from college. I studied mathematics in college and really enjoyed it and just assumed I would go on to graduate school. But I had all these college bills racked up so I decided to take a brief stint to work before applying to graduate school. I’m still on that “brief” stint.

ms: Apart from your work at Microsoft, you are active in open source work. You lead the Subtext Project, an open source blog engine on the ASP.NET platform. How did that come about?

ph: At my first job I really enjoyed the creativity in writing software but often chafed at many of the unfulfilling projects that I worked on, hoping to work on something more interesting. I also felt isolated working at a very small company in a place (Los Angeles) where there was The Industry and it wasn’t software. I just wasn’t connected to a lot of like-minded developers.

That’s when I discovered the triumvirate that in many ways has defined my career since then: RSS, Blogging, and Open Source Software. These three things connected me to a large world-wide community of developers interested in improving the craft of software and sharing ideas.

I tiptoed my way into open source. I started off by contributing documentation to RSS Bandit, an open source desktop RSS aggregator. Over time as trust grew, that led to commit access and I implemented a few small features. Around that time I also started playing with .TEXT and grew frustrated with how complicated the setup was. The author of .TEXT started a business with a few others and turned .TEXT into a non-open source product called Community Server.

At the time, I felt their product targeted a different audience from the hobbyist who wants to hack on a blog engine. Since .TEXT was effectively dead, I decided to fork it into a new project geared toward the hobbyist developer that I named Subtext.

That started my plunge into managing an open source project, which is in many ways like becoming a parent. At the time I had no idea of the level of commitment I was getting into and how much of my time it would consume. Not to mention all the sleepless nights.

ms: What led you to join Microsoft?

ph: Before joining Microsoft, my entire career had been in Los Angeles working on the Microsoft stack. I spent most of my first job writing web applications using Active Server Pages (ASP) and later ASP.NET.

I often hoped to work on software projects that allowed for more time to think about the long term rather than always writing software due yesterday. I thought working at a place like Microsoft building frameworks might provide more interesting work than the work I was currently engaged in, but I loved living in Los Angeles and didn’t really give it much thought.

But many years later, I was visiting Microsoft as part of a VSIP conference and I happened to go wandering in building 42 (where all the magic happens) to see who I might run into.

ms: Wandering the halls of Microsoft to see who you might run into is an interesting style of networking. How did it work out?

ph: It just so happened that I ran into none other than Scott Guthrie, a General Manager at that time, who wanted to show me something cool that the ASP.NET team was in the early stages of prototyping.

He drew an action method on the whiteboard and I was immediately sold. After he described what they had done so far, I told him immediately “I want to work on that!” and we got the ball rolling.

ms: So that gets you to Microsoft and involved with ASP.NET. What is the history of the MVC Framework? Was it developed as a result of developer requests?

ph: I joined Microsoft after the framework was underway, so I wasn’t there at the genesis. But as I understand it, the ALT.NET movement was a real impetus in its origins. At the time, a vocal group of ASP.NET developers were touting the benefits of the simpler model of web development embodied by Monorail, which itself was inspired by Ruby on Rails.

ASP.NET MVC was developed as an alternative to the existing Web Forms framework for building web applications for those who preferred this pattern of web development.

ms: One of the touted virtues of ASP.NET MVC is that it enables TDD. How important is it to your own development work?

ph: I’d be a pretty crappy developer if it weren’t for TDD, so yeah, I’d consider it pretty important to my own development work.

I remember when I was first introduced to it after reading some article about it. I didn’t grok it at first, coming from an ASP background. How could code test other code? That just didn’t seem reasonable considering the code I was writing at the time.

It wasn’t until my company hired a developer who was well versed in TDD and was willing to coach the team that I started to really grok the mechanics of TDD. Later, I realized the reason I didn’t grok it at first was that I was thinking about it in terms of the code I had written in the past. But TDD is a technique for shaping the design of code. The code I wrote using TDD looked nothing like the code I wrote before. It exhibited better separation of concerns, was more cohesive and focused, and was easier to change.

But it has been a long process of learning for me and I am still a student. For example, I take pride that Subtext started with 0 unit tests and now has over 1500. I’m ashamed at how many of them hit the database, though as a form of penance I am in the midst of a long-term refactoring to change that.

ms: Could you sketch out the argument for using ASP.NET MVC?

ph: There are many features of ASP.NET MVC that make it a compelling offering. One of my favorites is its support for binding submitted form inputs to arguments of an action method by matching up the name of the input to the argument name. With ASP.NET MVC, there’s no need to go foraging in a Request dictionary to extract submitted form values.

With a feature called model binding, we take it even further by binding submitted form values to matching properties of an input model. You can apply validation attributes on that model so that validation occurs when binding, and that validation can be “floated” to the client via JavaScript. This is a nice way to drive client-side validation based off of the validation applied to the model on the server.

The ASP.NET MVC framework itself is designed to reduce the friction for developers when writing unit tests of their code during development. It’s also extremely extensible, which many in the community have taken advantage of by developing custom view engines and other such features.

A big benefit of ASP.NET MVC is that it’s part of a larger family of well integrated products. ASP.NET MVC builds on top of a mature ASP.NET framework that provides performance, scalability, and a very solid well-tested platform.

And ASP.NET itself builds on top of the .NET Framework and the CLR. I particularly enjoy working with a modern language like C#.

ASP.NET MVC also leverages Visual Studio, which is a fantastic and powerful IDE. ASP.NET MVC layers on extensions to Visual Studio that allow you to easily scaffold a view while writing code via a keyboard shortcut or a context menu.

One of my favorite quotes about ASP.NET MVC was on Twitter from someone who said for them, ASP.NET MVC makes web development fun again.

ms: Can you characterize the developers who are using ASP.NET MVC?

ph: Originally, I thought the audience would primarily be the very advanced professional developer interested in TDD and this style of development. But I’ve found that the audience is much bigger than I expected and is all over the map. We have large enterprises like Dell taking a big bet on it as well as start-ups like StackOverflow.

ms: What’s been the reaction of developers with Ruby on Rails experience?

ph: It’s been a mixed reaction.

Some have not been favorable towards it, as they feel that a framework built on statically typed languages doesn’t have the expressiveness and elegance of code written in Ruby.

On the other hand, I’ve heard from many Rails developers who have found themselves working on a .NET project for various reasons and were very happy that ASP.NET MVC was an option for them. They found it to be a more familiar pattern to them than Web Forms and enjoyed working with it and gave it a thumbs-up.

ms: Well, thanks again, Phil. We really appreciate your taking the time to answer these questions.

ph: My pleasure.

Phil Haack is a megalomaniacal software developer with delusions of... well, uh, just delusions. As a code junkie, he not only enjoys writing software, but writing about software on his blog. By day, he is a Senior Program Manager at Microsoft on the ASP.NET team. By night he changes diapers while leading the Subtext Project, an open source blog engine. And no, they are not his own diapers. Send the author your feedback or discuss the article in the magazine forum.

The Mikado Method

Small- and Large-Scale Refactorings
by Ola Ellnestam, Daniel Brolund
Picking fights with the Hydra might sound adventurous, but it’s just not a good thing to do.

Once upon a time we worked for a client in a pretty small team who was developing a new software product. One day that company landed a new contract. Fortunately for us the new client needed an almost identical system to the one we were already developing. Just a few minor changes and maybe one or two bigger ones. Do you recognize this pattern? Are you thinking copy & paste?

As the sale was already made and time wasn’t really on our side, we basically had two options, and both would mean extra work. But in very different ways.

The Secret Parts

We learned early on that there were certain parts of the code that couldn’t be shared between our clients. Under no circumstances could one client see the other client’s secret parts. We had to separate the sensitive business logic and be able to configure which parts should be delivered to each client.

One way of solving that problem was to copy most parts of the code base to a new project and modify the code there. That would have solved the immediate problem: no sharing of sensitive code between the two customers. But a duplicated code base or a partly duplicated code base would mean a lot of extra work.

On one hand, we would be able to deliver really fast, as we wouldn’t have to think about how to structure the code to minimize duplication. On the other hand, that would of course mean we would have had to maintain almost twice as much code, including our previously poorly structured code, bugs and all.

Also, for every future bug or change in the system, we would have to analyze both parts to see if the bug was on the other system as well. In the long run, this would have meant tons of extra work, not to mention that it’s a very error-prone approach. Add to that the fact that it would have been a real pain to work with.

If we chose this path we would have had to pay a lot of interest on this huge technical debt. But initially it wouldn’t cost us much, just copy some code. Ship it! Done.

If we instead opted for a large restructuring, we could still serve both customers and no sensitive data would be shared between them. This path meant we had to do some thinking, restructuring, and up front extra work before we could deliver to the new customer. The later coming interest would be lower, since the amount of duplication could be kept to a minimum. But if we chose that approach the customer would have to wait longer.

This was not an easy decision, and after many long and heated discussions we agreed to restructure the code base. Just give us a month, and we would be done.

We started working, and guess what? The work was more complex than we initially thought. Our approach got us into troubles of enormous proportions.

We didn’t realize it right away, but we were up against a big refactoring.

Enter the Mikado Method

Mikado is a pick-up sticks game originating in Europe. In 1936 it was brought from Hungary to the USA and was mostly called pick-up sticks. Probably the “Mikado” name was not used because it was a brand name of a game producer. Anyway, the game got that name from the highest scoring stick, the “Mikado,” named for the Emperor of Japan.

You can play Mikado with two or more players. You have a bunch of sticks, much like dried spaghetti sticks. You bundle them with your hand and while keeping them in a vertical orientation, standing on a flat surface, you just let them fall. They will form a pile of some kind. In the middle of the bundle you have a differently colored, high-scoring stick, the Mikado. The goal is to pick up the Mikado stick. If as you are picking up one stick another stick moves, you have to drop the stick and the turn goes to the next person. While you pick up sticks without disturbing other sticks, you may continue. The trick is to pick up the easy sticks, typically sticks that have no other sticks on top of them. Eventually, by using that strategy, you can pick up the Mikado stick and win the game.

Goal-Driven Change

Code changes are like the Mikado game. When you want to make changes to a code base, you can rarely make the exact changes you want right away. You have to prepare some, move code, extract classes, and much more. Picking up the Mikado on your first grab is a rare thing! More often you make a sequence of moves before the Refactoring Mikado is available, working your way systematically to the bottom of the pile, to reach your goal.

We had thrown ourselves into an improvement-and-change frenzy, modifying parts of the system that other parts depended on. Every change left us with an even more stirred-up system, with more and more compilation errors.

Using the Mikado metaphor: We had set our eyes on the highest scoring stick, which was at the bottom of the pile, not realizing this caused sticks to fly all over when we reached for it.

Pretty soon we realized that we needed to do everything we already had done, but in the reverse dependency order. We needed to follow those dependencies, or prerequisites, until we reached a change that had no prerequisites. The changes and dependencies between them constitute what we call the Mikado graph. Any change that has no prerequisites we call a leaf. These leaves are the only changes in the Mikado graph that are allowed to be made, since they can be done without stirring up the system with compilation or run-time errors.

We draw the prerequisites to the goal in a graph, on a whiteboard. By performing the leaf changes, we expose new leaves, ready to be pruned.

Removing a leaf is the same as picking up the top-most sticks in the Mikado stack. By doing so, you make other sticks the top-most sticks and easier to pick. If you follow that strategy, soon enough all obstacles will ultimately be removed and the goal will be within your reach.

After long and hard work we were finally able to pick the highest scoring stick. We had reached the Mikado goal.

The Mikado Game usually continues until all sticks are picked up. The problem in software development is that there’s an endless pile of sticks. You can go on forever improving a system unless you decide which stick is your Mikado.

Let’s see how Mikado Graphs can be created!

Creating Your First Graph

The Mikado Graph is a way to visually represent the knowledge about what changes depend on other changes. There are several ways to create such a graph, and we will start with one of the most powerful ways we know of: The naïve approach.

Let’s draw our goal, the Mikado Goal, on a piece of paper or a whiteboard, like this:

Once you’ve done that, you start by trying to achieve it immediately.

If you can easily achieve the goal, congratulations. Check-in and you’re done. But if you can’t, you need to start exploring and find out why.

To get going we usually try the first or easiest thing that pops into our minds. We’ve found out that this works really well and it gets you going.

We naïvely try to implement a change, without analyzing too much in advance. By doing so, you don’t need to think about how this affects the other changes and what that might lead to, thus ending up in analysis paralysis. You just do it!

As a start, you only need to know what you want to achieve, your core change. You don’t have to know how to deal with all the complications in the system to make this change possible.

Very often when you make a naïve change, you realize that the system is not built for the type of change you want to make, be it a mess or a well-built system. When dealing with such a system, you need to perform some prerequisite refactorings first.

These prerequisites often manifest themselves in compilation errors or test failures. Don’t try to fix the errors immediately or you will fall in the same trap we did. It will be like fighting a Software Hydra—for every head you cut off, two more grow out. Picking fights with the Hydra might sound adventurous, but it’s just not a good thing to do.

Instead, analyze the situation just about enough to decide on immediate actions that would resolve the errors. Draw those as dependent sub-goals, or prerequisites, in your newly created Mikado Graph. After creating that memento you must revert your (broken) changes. Then you try to implement each of the prerequisites in the same way.

The Power of Undo

When you’re working with computers you have a great tool that you sometimes would like in the real world: Undo.

Let’s say we’ve started to refactor and made our first change to the system and noted all changes that break the system as nodes. Our system is now upset: “the sticks are all over the place.” This means we cannot compile or run the tests. We have put ourselves in a bad situation, because the state of the system doesn’t allow safe progress any longer. It’s time to get back to the last known good state. We need to revert our recent changes.

In your version system Undo might be called revert or roll-back. But it is an undo: it allows you to take risks and test things you would not, or could not, do in real life.

In his book Working Effectively with Legacy Code, Michael Feathers calls this approach Scratch Refactorings—changes you do only to explore your options, after which you return the code to its initial state. We will use that approach systematically.

We cannot stress this enough: Always revert changes that don’t work. We don’t recommend working with a broken code base, even if you’re a professional. Neither the compiler nor the tests will be able to help you when the code is in such a state.

To some people, reverting the (broken) code is like throwing work away and starting with nothing, like it never happened. This is a misconception of what developing systems is about: System development, and especially refactorings, is almost exclusively about learning the system, the domain, and the language and technology you are using. Actually executing the changes takes just a short slice of the total development time.

The real value of the naïve approach is that you learn what actually stands in your way. The Mikado Graph will hold that information for you, to be used and executed at a later time. Hence, nothing is really lost when reverting, but on the contrary, the stage is set and cleaned to execute some changes that might compile and work.

Avoid Analysis Paralysis

If you don’t know what the consequences of your fix for the errors will be, again choose a naïve resolution to the problem. If you realize that there are even more actions you need to take in order to make it work, which are not shown by the compiler or the tests, note these as prerequisites as well. This way, you make use of all available tools and knowledge when you later decide what to do while still saving time by being naïve.

Remember: Stay out of analysis-paralysis by being naïve. As a rule of thumb, if you have been thinking for more than a couple of minutes you should probably try something naïve and practical again.

The naïve approach is a way to create the Mikado Graph empirically. By avoiding analysis paralysis and too much guessing, you let the feedback be your compass, guiding you to your next step. This may sound strange, but it actually works very well in practice.

Different Types of Nodes

If you analyze a Mikado Graph you will find that it’s actually made up of four different types of nodes, the most central one being the Mikado Goal. It is connected to the prerequisites. At the very edge of the graph there are leaves. There is one more common node, the decision node. It represents things you need to do, but you are not yet sure what you need to do.

Mikado Goal

We recommend that this node be as clear and precise as possible. If it isn’t, there will probably be some arguments on whether or not you’re done. Spend some time and try to find what your acceptance criteria are. The goal itself could be either a technical one or a more business-focused goal; that is really up to you. Our bias is toward the latter even if we use this approach for technical improvements.

Did you notice that we drew the Mikado Goal with a double ellipse, or double circle? We do that to make it clearer which is the main goal, and which are sub-goals. In small graphs this is usually not a problem. But when you jot it down on a piece of paper with lots of nodes and dependencies, you, and especially others, will benefit from finding the goal without guessing.

Prerequisites

Very often when you deal with large improvements you realize halfway through that what you really wanted to achieve has already been done. That is why we sometimes call this node-type a subgoal.

Leaf

If you step back some and squint your eyes a bit, a Mikado Graph can look a bit like a tree, with a trunk and branches. At the end of each branch there is a leaf ready to be removed. In the same sense you find nodes at the outer border of the graph. When you have built the graph inside-out, you start pruning the leaves outside-in, in order to reach your goal. Sometimes, when you work on a leaf, you discover it also has prerequisites. This is quite all right, and is a part of the process.

Decision Node

Sometimes you know what you want to achieve, but not exactly how to achieve it. In those cases you can postpone the decision of how to do it by using a decision node. An example is if you want to Break cyclic dependency between Game and Player.  Later, you can add nodes as prerequisites to that node that spell Extract Game interface and Inject Game instance to Player.

Conclusion

The Mikado Method can help you find the troubling dependencies any large refactoring is affected by. You build the Mikado graph using the naïve approach from your goal and out. By drawing the graph, you ensure that those dependencies are remembered and communicated to fellow workers or the future you, like a memento. By working the Mikado graph from the leaves in, you can perform big changes while keeping the system in a deliverable state, all the time.

We hope that you now have enough information to start practicing safe transformations of code bases. Deep in our hearts we believe that ripping apart and putting together systems is much harder than morphing them to a new better shape. The Mikado method can help you do that.

Good luck!

Ola Ellnestam likes to combine technology, people and business. This is why he finds software development so interesting. After stumbling upon eXtreme Programming back in early 2000 he realized that software development can be rewarding for both business and developers. But more than anything else, he likes to share his insights with others because he believes that this is how new knowledge and new insights is created.

Daniel Brolund is a software developer and co-founder at Agical. Among his traits is a constant desire to improve. He has successfully worked with global web sites deployed on hundreds of servers, desktop applications for just a few users, on-line gaming applications, just to mention a few. In a previous life he has also walked death-marches and been involved in a huge big-bang catastrophe. Send the authors your feedback or discuss the article in the magazine forum.

When Did That Happen?

Alan Mathison Turing
by Dan Wohlbruck
Every electronic computer ever built—and the languages that direct them—trace their roots to Alan Turing.

On June 23, 1912, Alan Mathison Turing was born in Paddington, England. He would have been 98 this month. When Turing was born, a computer was someone who made computations, usually long and tedious, the answer to which might predict the ebb and flow of the tides or the next date for an eclipse of the sun. In his lifetime, Turing changed the meaning of the word computer from the description of a person to that of a machine that could do what humans did.

Today, Alan Turing is best remembered for his test of artificial intelligence. He proposed that if a machine could make a human questioner believe that the machine was human, then that machine could be said to have intellect. His 1950 article, “Computing Machinery and Intelligence,” proposed how the test could be conducted and also suggested how a machine could be trained. The Turing Test has become an AI benchmark.

The Entscheidungsproblem

Turing’s true greatness—his genius—however, rests on another article, published in 1936 while he was a fellow at King’s College. The article is titled, “On Computable Numbers, with an Application to the Entscheidungsproblem.” In 1917 the German mathematician David Hilbert asked for proofs to three questions. His third question asks if a mechanical procedure exists that can be used to decide the solvability (computability) of formulas in 1st-order logic. It is this question that is called, in German, the Entscheidungsproblem. By the time that Turing became interested in Hilbert’s questions, Gödel had published his Incompleteness Theorems that successfully dealt with the first two of Hilbert’s questions. Turing took up the challenge of the third question, finding a general, mechanical process for dealing with the solvability of algorithms.

In the first paragraph of his paper, Turing defines a computable number as a real number whose expression as a decimal is calculable by finite means. He concludes his definition by saying, “... a number is computable if its decimal can be written down by a machine.” Turing goes on to provide this basic description of the machine that would do the computing:

“The machine is supplied with a ‘tape,’ running through it, and (the tape) is divided into sections (called ‘squares’) each capable of bearing a ‘symbol.’ At any moment there is just one square ... which is ‘in the machine.’ We may call this square the ‘scanned square.’ The symbol on the scanned square may be called the ‘scanned symbol.’”

Having described the architecture of his machine, Turing describes its operation as proceeding step by step. A step goes from one configuration to the next. The description of a configuration includes the location of the read-and-write head, what is on the tape at that location, and the configuration after reading what is on the tape.

And that is what Turing called an a-machine.

The principles of operation for the a-machine indicate that each program step has a command (read, move the tape, print, or erase) and a configuration setting. As presented by Turing, an a-machine instruction would be in two parts: first the command which is informed by the configuration, followed by a setting of the configuration.

Turing then makes this amazing statement, “It is my contention that these operations include all those which are used in the computation of a number.”

Turing gives this a-machine, as he gives to all of his a-machines, a standard description number. The Turing number (we can think of the number as a description of the program) is like a serial number in that it identifies the specific function that was computed by a given machine. The standard description identifies, step-by-step, the configurations, symbols, and actions taken by the machine as it works through the solution.

The Concept of Computability

Returning to Turing’s paper, he then posed the question at the core of the computability problem itself. Could a machine be built, to be called the Universal Machine, which would take as input a Turing machine’s standard definition number, use the same set of configurations and the same architecture as the basic a-machine, and determine if the underlying formula or function was provable? Turing then set about to describe just such a Universal Machine.

The Universal Machine is a programmable computer. When the Universal Machine is executing a program that is the coded standard description of an a-machine, it makes itself behave as if it were that a-machine. Given the same input as the other machine, the Universal Machine will produce the same output.

Turing suggested that a given algorithm processed by one of his a-machines would be either circular (think endless loop) or circle-free. The Universal Machine, when it completed its simulation of the a-machine’s work, would print either a 0 or 1 to signify that the result was circular or circle-free. If the algorithm was circle-free, it had a finite solution. After six more pages of rigorous proof, Turing concluded:

“We are now in a position to show that the Entseheidungsproblem cannot be solved.”

Turing’s argument was straightforward. His machines could compute any function that had a solution. There are some things, however, for which no proof exists. In the 75 years since Turing published his paper, his extraordinary claim has held up: it has been shown that the basic Turing machine can compute all of the algebraic numbers.

Defining the Computer

Although the mathematical result that was the essence of Turing article was of great theoretical importance, a side-effect of its publication was arguably of far greater practical importance. Here, as part of Turing’s proof, was a rigorous specification of a mechanical device that included input, output, memory, and the ability to process algorithms expressed as commands. A computer.

Of course, Turing’s Universal Machine was theoretical. It wasn’t until a number of developments, including John von Neumann describing what would come to be known as the von Neumann architecture for computers with internally-stored programs, that an actual Universal machine would become a reality. Every electronic computer ever built is such a Universal machine, and every such machine and the languages that direct them can trace their roots to Turing.

Alan Turing lived to see only the beginnings of his ideas becoming reality. After a distinguished career as a code-breaker during World War II, Turing spent a few years at one academic appointment and a few more years writing programs for the University of Manchester. Then, on June 7, 1954, he took his own life by poisoning.

Alan Turing died fifty-six years ago, but his genius lives on. It all started in June 1912—and that’s when it happened.

Dan Wohlbruck has over 30 years of experience with computers, with over 25 years of business and project management experience in the life and health insurance industry. He has written articles for a variety of trade magazines and websites. He is currently hard at work on a book on the history of data processing. Send the author your feedback or discuss the article in the magazine forum.

Better Tools and Training

A Different Spin on Static Analysis and Some Thoughts on Developer Internships
by Brian Tarbox
Brian suggest a way to improve static analysis and argues that software teams could learn something from Denny’s when it comes to on-the-job training.

I’m currently helping another group within my company develop a set of coding standards, and introducing them to some of the static analysis tools that my group uses such of Findbugs, PMD, and Checkstyle (and learning about the tools that they use as well).

Along the way a conclusion finally crystallized for me: our current set of static analysis tools is working on the wrong level.

All of the tools parse a class into bytecode, generate an abstract syntax tree, and then analyze that tree. That’s fine for finding a certain class of problems. Where it fails, however, is that it does not operate on the code at the same level that we engineers operate on, namely the text level.

Even the tools and rules that do operate at the text level are very simplistic. Yes, we should limit the length of the lines and length of the methods, and yes, we should limit the cyclomatic complexity of a module. Yet none of that moves us closer to beautiful code—i.e., code that sings. It may seem a ridiculous goal at times but we really can write elegant code that people enjoy reading. Code like that tends to be simple and bug-free.

Learning from PowerPoint

Let’s take an example from another domain. There are lots of style guides available for creating PowerPoint presentations. They suggest rules such as: a) use a readable and standard font, b) limit yourself to 5 or so bullets per slide, c) think about the use of color if you want people to print your slides.

You can follow all of these guidelines and still create a terrible presentation. We’ve all sat through these presentations. The problem is that the style guides are a necessary but not a sufficient set of rules for presentation “goodness.” They do not ensure that the slides say something, that the bullet points at least occasionally include a verb, and that there is some internal consistency and flow to the slides. Grammar checkers can help to some degree, except that we expect PowerPoint bullets to be sentence fragments, so the signal-to-noise ratio gets pretty low.

There is a piece, however, that we can address, both for PowerPoint presentations and for software code. I believe that poor naming contributes far more bugs to code than most of the items specified in most “rules.”

There is a famous quote about code: “you can write code so that it is obvious there are no bugs in it, or you can write code so that there are no obvious bugs in it.” If you see a line of code like windSpeed = todaysWeather.getWindSpeed(), I’m quite confident that you’ll be able to read it and that it is unlikely to have bugs in it. Yet no tool that I’ve found even seems to look at code at the surface level.

Imagine if we built such a tool.

Analyzing Code for Readability

I’m picturing a Spring/Groovy program that would scan a specified directory for source files, and then use reflection to extract the names of the class and methods. These identifiers will then be analyzed for readability.

This will be the admittedly tricky part of the system. We certainly don’t expect to find things like “updateCacheInterval” in a standard dictionary. On the other hand we do have a simple lexical rule to split that identifier into “update,” “Cache,” and “Interval,” all of which are in a standard dictionary. This works on the assumption that camel casing is the standard these days for dealing with longer names. I hardly ever see names like update_cache_interval anymore. This gives us hope that the approach might have some traction behind it, so let’s look at some other cases.

Methods with names like parseXYZParameters are fairly common but can also be handled by rules that look for camel case boundaries plus acronyms. This method might get a score of “two out of three plus one acronym.” A system such as this one will by necessity output a grayscale of goodness, and that’s OK. It can also be enhanced to look for word category. If we follow Knuth’s Literate Programming model, method names should include a verb and objects should be nouns.

We could score a method higher if at least one of the words in the name was a recognized verb. We could go a step further and analyze the parameters to the methods, hopefully finding mostly nouns in their names.

I mentioned that this would be a Spring-based application because of the clear need to be able to inject new algorithms. It would not surprise me to find that there are existing open source libraries for parsing computer identifiers into “words.” My camel casing idea is definitely just a first step. There is also a variety of open source dictionary systems available.

Mike Taylor quoted Bjarne Stroustrup in a recent PragPub article, and I’m going to repeat the quote as it is very applicable: “Design and programming are human activities; forget that and all is lost... There are no ‘cookbook’ methods that can replace intelligence, experience and good taste.”

Interns Need Exposure to Great Code

This shifts us into the question of how we teach young programmers this “intelligence, experience and good taste.” Most professions have some sort of apprentice program where students learn the trade. Doctors have internships; lawyers have clerks and paralegals; architects, electricians all have an apprentice program of some sort. The commonality of all of these is that the student observes the expert being an expert. They are exposed to the best practices of the profession and hopefully absorb them.

Compare that with entry-level jobs or internships in our field. Summer interns at most companies are given little to no training and often work on low-priority tasks like cleaning up a bug backlog. Most companies I’ve worked at have viewed getting an intern as a mixed blessing. You hope to find something discrete for them to work on without slowing down your “real” engineers.

The bottom line is that our interns get exposed to the worst code with minimal or zero supervision from the experts. Try to think of a time when a young programmer would ever get a chance to read great code. There isn’t any such time. And yet, we are then surprised when our new engineers are not imbued with the spirit of creating beautiful code.

We tend to have meetings to discuss problems, but we should really have meetings to walk though excellent code so that people get exposed to examples of what we hope to be producing. Even better would be to adapt the notion of pair programming and let the interns shadow an expert. Way back when I worked a summer job at Denny’s (we’ve all had that job, right?), the newbies spent a week or so shadowing an experienced worker. They didn’t interact with the customers or cook the food, but they watched as the experienced people did.

How many engineers out there ever got the chance to sit with a top programmer and watch them work? Watched them use their tools with precision and dexterity? Saw that they used google as their exo-cortex, and saw them think, then write a test, then write the “real” code?

We want our coworkers to have all of these great habits, but chances are none of them got even the level of on-the-job training that your average waiter at Denny’s got. Perhaps we ought to change that.

Brian Tarbox is a Principal Staff Engineer at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com. Send the author your feedback or discuss the article in the magazine forum.

The Indispensable Developer

How to Keep Yourself Indispensable
by Jonathan T. Rasmusson
Jonathan takes a break from writing The Agile Samurai to share the four things that will make you indispensable.

Jonathan Rasmusson teaches developers how to become an agile samurai. By learning the ways of the agile samurai you will discover:

- how to create plans and schedules your customer and your team can believe in

- what characteristics make a good agile team and how to form your own

- how to gather requirements in a fraction of the time using agile user stories

- what to do when you discover your schedule is wrong, and how to look like a pro correcting it

- how to execute fiercely by leveraging the power of the agile software engineering practices

In this succinct essay, Jonathan focuses on how to make and keep yourself indispensable as a developer. -MS

When you start your career as a developer it’s easy to fall into the trap of thinking that your job is all about the coding. It isn’t.

Sure, you need to know the mechanics of your programming, and yes, you need to know how to refactor, unit test, and do basic design. But coding by itself isn’t enough. Not enough to become indispensable.

Know the Customer’s Business

To be indispensable you’ve got to know your customer’s business—inside and out.

If you don’t know the business like the back of your hand, how else are you going to come up with the brilliant innovations, insightful breakthroughs, elegant designs? You can’t. That’s why you’ve got to go and sit with your customer. Feel their pain. Then, and only then, will you be in a position to help.

Be Serious about Testing

The indispensable developer is also serious about testing.

Great developers take pride in what they do and don’t pass the buck on quality. They write tested code that works. That doesn’t mean that they are perfect or that no bugs ever get through. But the best test hard, and secretly strive to do everything in their power to make User Acceptance Testing (UAT) a non-event.

Care about the User’s Experience

The indispensable developer also cares greatly about the user’s experience.

Much like an animator is really an actor with a pencil, they view themselves as a customer with a keyboard. To them the user experience, and how their users interact with their software, is just as important as how it is built. Never an afterthought, the User Interface is front and center from day one and stays their for the life of the project.

Own the Process

Finally, the indispensable developer knows how to set and manage expectations. They know when to commit (and when not to). They know how to size things up and set expectations around dates. And they know how to get feedback, roll with the punches, and adapt the plan as necessary.

If this sounds like a lot for one person to do, it is. That’s why there are so few indispensable developers. But if you really want to separate yourself from the rest of the pack and avoid becoming a commodity (which most developers are) you’ve got to be flexible and do more than just code.

You’ve got to become indispensable.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. Send the author your feedback or discuss the article in the magazine forum.

The Quiz

Local Integrated Software Architecture?
by Michael Swaine
This month we present another Sudoku puzzle with a couple of twists—it uses letters instead of digits, and there is a hidden message. In one of the rows or columns of the solved Sudoku, you will find what Lisa was to Apple.

Simply fill in the empty cells with the nine unique letters you’ll find in the grid in such a way that each row, column, and small square contains each of the nine letters exactly once.

C

N

B

K

A

O

K

Y

N

R

B

M

K

M

C

N

R

O

N

R

C

C

M

O

R

Y

Solution right here next issue. Or on Twitter right now, no doubt.

Solution to Last Issue’s Quiz

We hid in these four unusual headlines several things that should be meaningful to any software developer:

- Quakes Bury Typhoon

- Landlady Feels Conic Abscissa

- Alpacas Repel Sesame Allergen

- Googling Froth Spills

We used Wolfram Alpha’s Letter Bank search expression to find these fourteen words with programming languages hidden in them. They are not quite acronyms, but close. Unlike acronyms, Letter Banks can contain extra copies of letters from the original words. Here are the fourteen words and the programming languages hidden in them:

quakes

squeak

bury

ruby

typhoon

python

landlady

dylan

feels

self

conic

icon

abscissa

basic

alpacas

pascal

repel

perl

sesame

mesa

allergen

erlang

googling

lingo

froth

forth

spills

lisp

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

- June 1–4, XP2010, Trondheim, Norway
Workshop: “Trust and Culture”Rachel Davies, author of Agile Coaching

- June 1–4, Open Source Bridge
“Give a Great Tech Talk” (with Josh Berkus)Ian Dees, author of Scripted Gui Testing with Ruby

- June 6–11, Better Software Conference/Agile Development Practices, Las Vegas, NV
“It’s the People, It’s Always the People”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- June 7–10, RailsConf, Baltimore, MD
“System Testing Rails Itself”Sam Ruby, author of Agile Web Development with Rails, Fourth Edition

- June 7–10, RailsConf, Baltimore, MD
“Acceptance Testing with Cucumber”David Chelimsky, author of The RSpec Book

- June 7–11, Better Software/Agile Development Practices
Keynote: “From Big Boss to Servant Leader,” tutorial: “Agile Retrospectives,” talk: “Card, Conversation, Confirmation: Interviewing Skills for Agile Requirements,” and talk: “The Art of Giving and Receiving Feedback ”Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

- June 8, UniForum, Chicago
“What’s New in Perl 5.10 and 5.12”Andy Lester, the author of Land the Tech Job You Love

- June 8, Embedded Systems Conference, Chicago, IL
“Testing Embedded User Interfaces”Ian Dees, the author of Scripted GUI Testing With Ruby

- June 8, Sacramento Java User Group
“Grails Integration Strategies”Dave Klein, the author of Grails: A Quick-Start Guide

- June 14–17, UberConf, Denver
“The New Work of Management in Agile Organizations” and “Working with Complex Adaptive (Human) Systems”Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

- June 14–17, UberConf, Denver
“Test Driven Development in Java: Live and Uncensored,” “Continuous Testing on the JVM,” and “Iteration-less, Value-Based Planning”Ben Rady

- June 14–17, UberConf, Denver
“Grails: Bringing Radical Productivity to the JVM” and “Grails Integration Strategies”Dave Klein, the author of Grails: A Quick-Start Guide

- June 14–17, UberConf, Denver
“Clojure,” “Introduction to Functional Programming with Clojure,” and “The Best of OO: Clojure Types and Protocols”Stuart Halloway, the author of Programming Clojure and Rails for Java Developers

- June 14–17, UberConf, Denver
“Transforming to Groovy,” “Scala for Java Programmers,” “How to Approach Refactoring,” and “TDD Regular Code/Multithreaded Code!”Venkat Subramaniam, the author of Practices of an Agile Developer, Programming Groovy, and Programming Scala

- June 14–17, UberConf, Denver
“17 Lessons Learned: Secrets of Great Management,” “Agile Program Management,” “Manage Your Project Portfolio: A Lean and Agile Approach,” “Overcoming Several Pitfalls of Transitioning to Agile,” and a workshop: “Coaching as a Two-Way Relationship”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- June 20–22, OGF29 Cloud Interoperability
“Demo of DataCloud interoperability”Krishna Sankar, author of the forthcoming Building Clouds with Amazon Web Services

- June 22–24, Public workshop, register through Agile University, Portland, OR
“Secrets of Agile Teamwork”Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

- June 23, DevDay for iPhone, Geneva
talk: “Core Animation” and tutorial: “Programming the iPad”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- June 25, DevDay for iPhone, London
talk: “Core Animation” and tutorial: “Programming the iPad”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- July 9–10, Agile Coaches Gathering, Bletchley Park, UK
“Facilitating Open Space”Rachel Davies, author of Agile Coaching

- July 16–17, Ruby Midwest, Kansas City, MO
“Pragmatic Guide to Git”Travis Swicegood, author of Pragmatic Version Control Using Git

- July 19–23, OSCON
“Building a NoSQL Data Cloud”Krishna Sankar, author of the forthcoming Building Clouds with Amazon Web Services

- Aug 9–13, Agile 2010, Orlando, FL
“Improving Customer Conversations” and “Manager as Work System Designer: 13 Essential Questions”Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

- Aug 9–13, Agile 2010, Orlando, FL
“Agile Coaches Dojo” and “Refactor Your Retrospectives”Rachel Davies, author of Agile Coaching

- Aug 9–13, Agile 2010, Orlando, FL
“Exploring Coaching From Multiple Dimensions and Levels,” Agile Managers: The Essence of Leadership,” and “Agile Program Management: Another Approach to Large Projects” Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Aug 28, RubyKaigi 2010, Tsukuba, Ibaraki, Japan
“A Metaprogramming Spell Book (for Ruby and Rails)” Paolo Perrotta, author of Metaprogramming Ruby: Program Like the Ruby Pros

USENIX Events

- June 23–24, USENIX Federated Conferences Week, Boston, MA
WebApps ’10 is a new technical conference filled with the latest research in all aspects of developing and deploying Web applications. The diverse 2-day conference program will include invited talks by industry leaders including Adam de Boor, Google, on “Gmail: Past, Present, and Future,” a variety of topics and new techniques in the paper presentations, WiPs, and a poster session. Since WebApps ’10 is part of USENIX Federated Conferences Week, you’ll also have increased opportunities for interaction and synergy across multiple disciplines. Register by June 1 and save up to $400! Additional discounts are available.

- June 23–25, USENIX Federated Conferences Week, Boston, MA
The 2010 USENIX Annual Technical Conference (USENIX ATC) will again bring together leading systems researchers for cutting-edge systems research and unlimited opportunities to gain insight into a variety of must-know topics, including virtualization, system administration, cloud computing, security, and networking.

O’Reilly Events

- June 7–10, Baltimore, MD
RailsConf is the largest official event for the Ruby on Rails community. If you’re passionate about Rails and what it helps you achieve—or are curious about how Rails can help you create web applications better and faster—RailsConf is the place to be.

- June 22–24, Santa Clara, CA
O’Reilly’s Velocity Web Performance and Operations Conference gives attendees access to speakers and the in-depth, technical content that will move the dial furthest for Web Ops and Development professionals most responsible for the health of their company’s IT infrastructure.

- July 19–23, Portland, OR
At OSCON you’ll participate in hundreds of sessions covering open source languages and platforms, practical tutorials that go deep into technical skill and best practices, inspirational keynote presentations, an Expo Hall featuring dozens of the latest projects and products, fun networking events and activities, and the best “hallway track” around.

Other Happenings

- June 8
Tim Berners-Lee is 55.

- June 23
Vint Cerf is 67.

- June 30
Unix guru Lynne Jolitz is 49.

- July 9
Browser pioneer Marc Andreessen is 39.

- July 16
VisiCalc co-creator Dan Bricklin is 59.

- Aug 9
Alfred Aho, co-creator of AWK language, is 69.

- Aug 11
Steve Wozniak is 60.

- Aug 20
Game developer John Carmack is 40.

- Aug 29
Boy genius Stephen Wolfram is 51.

Shady Illuminations

HP Buys Palm? No Way!
by John Shade
John ponders HP’s decision to buy Palm, but reaches few solid conclusions.

There are certain historic decisions that everybody knows were just stupid. In technology, it’s surprising the number of these that involve Apple. Xerox Parc was stupid to let Steve Jobs see its company secrets. Ron Wayne was stupid to sell his founder’s interest in Apple for a pittance. Hewlett-Packard was stupid to turn down the Apple 1 when Steve Wozniak offered it to them.

I guess I’m too stupid to know what everybody knows.

It seems to me that the stupidity at PARC wasn’t that Steve Jobs saw the promise of PARC technology, but that Xerox didn’t. The researchers at PARC had built a lot of cool stuff. Xerox corporate didn’t seem to get how cool it was. The PARC geniuses wanted to be appreciated. Jobs gave them what they wanted. Oh, and the team from Apple weren’t the only the PARCers gave demos to.

Ron Wayne? I have no trouble putting myself in his shoes and coming to the decision he reached. Of course, I just admitted that I might be stupid, so what’s my point? All right, you do the thought experiment: Do you go with the crazy-eyed hippie who says he’s going to build a Fortune 500 company in five years, or do you take the cash? Easy choice, right? I have more trouble putting myself in Steve Jobs’s shoes since, in my mental reconstruction of that conversation, he wasn’t wearing any.

Not that there’s anything wrong with that. Steve Jobs being Steve Jobs has worked pretty well for Steve Jobs, and it’s done all right for Apple. Apple wouldn’t have happened without him. Which is why making fun of Hewlett-Packard for passing on Woz’s little project doesn’t appeal to me. HP made the right decision. Even if they had turned Woz’s computer into a product and sold the bejeebers out of it, it would have been just another HP product. HP wouldn’t have become Apple. There is no imaginable scenario in which HP becomes Apple.

Today, though, they’d kinda like to try.

Even tech journalists, traditionally the last to notice, are starting to understand that the market has changed. The personal computer era is over. Apple anticipated it and made its moves at the right time and with the right boldness. The end of the personal computer era means that the concept of a computer is fragmenting into multiple categories of smart devices. The desktop is no longer the center of the computing universe. The center is mobile. WIMP and hierarchical directories are no longer acceptable for user interfaces. The new model is built around gestures and touch and conventions foisted on a gullible user base without usability testing or an undo option. The new model involves apps that are cheaper, smaller, and dependent on a fragile connection to the “cloud,” a connection that you’ll pay for by automatic withdrawl—for your convenience.

So in this brave new world, HP bravely gobbles up Palm.

I would so like to ridicule that decision. I just don’t know if I can. Particularly if buying Palm, and with it WebOS, means that HP is truly bailing on Microsoft. But being a big company, they probably won’t. They’ll hedge their bets, on the theory that if you pursue all the options one of them has to pay off and once you know which one it is you just kill off the losers.

You can certainly make a case that HP paid too much for Palm, but you’d have to know what they thought they were buying. The devices and the technology behind them? But HP has been making high-quality handheld devices since before anybody, so do they really need the baggage of Palm’s devices? WebOS? Or maybe the talent? Too bad, then, that some of that talent is bailing. It’s hard to buy people.

It seems like they mostly wanted WebOS, the third or fifth player in this mobile OS market. Third or fifth is still better than Microsoft’s position, though. At least WebOS actually is a player.

So is HP being stupid or making the right move at, for them, the right time?

I don’t know how to assess that, except to ask whether HP has been generally smart or stupid in the big decisions it’s faced over its lifetime. Let’s see.

The HP Way was pretty smart. It got them quality products and happy, respected employees, a great reputation, and profits. It worked for them.

Until it didn’t. Until the company was struggling. Then they brought in a shakeup artist who repealed the HP Way, merged the company with Compaq, and then went on to make videos about alien robot sheep. So there’s that.

Now, though, they want to jump into the iThing end of the pool. HP has always swum in the geeky end of the pool. Can they do consumer? It’ll be fun to watch them try.

The moral of the story? Beats me, but here’s a detail I like: If you walk out of the West door of the San Jose Convention Center, cut across the parking lot and across the little Guadalupe River, you’ll soon find yourself in front of the Children’s Discovery Museum. From the parking lot to the Museum, you’ll have been walking along a street named Woz Way for Steve Wozniak. HP rejected Woz, HP lost its Way, Woz found his. It must mean something.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He’d like to take a brighter view of things, but it’s just not his Way. Send the author your feedback or discuss the article in the magazine forum.