The Master Stumbles

I watch Steve Jobs' keynote presentations in part because I'm an Apple fanboy, but mostly because he gives outstanding presentations.  It's inspirational and instructive to watch the master at work.

It's also instructive when the master fails.

The recent antenna-gate press conference was Jobs not at his best.  This is a quick look at where I thought he could have done better.

Rehearsal.  Clearly, the usual Jobs presentation is very well rehearsed.  This isn't just about practice, this is also about editing - as you practice, you realize this bit is a little too wordy, this slide is a little too busy and it helps hone the overall presentation, not just the act of presenting.  The antenna-gate presser didn't have the usual polish.  The slides were overlong, some of the material as presented was a bit long winded and, worst of all, Jobs came across as peevish.  I understand where he's coming from, this had an engineering "you just don't get it" quality which I've seen many times, but that's no excuse.  He clearly had his facts down, but that's only part of the equation.  Rehearse, polish and, when the time comes, present with the right attitude.  Don't stint on rehearsal, no matter what the pressure.

Dead Time.  There was a dull stretch while antenna-gate problems were demo'd on competing phones.  This was a good idea and good points were made, but waiting for bars to drop was like waiting for paint to dry.  Not something you wanted to watch.  It might have been more fun to have had a more thorough and crisp introduction (some algorithms will respond slowly for the following reasons, your mileage may vary in these other ways, etc) and then have all the phones up at the same time racing towards their fail points.  Kind of an antenna-gate pinewood derby.  Silly, but something to make the point more lightly rather than the "and this one sucks too" march through the competition.  Don't be boring.

Core Values.  Towards the end, Jobs walked through what was, in effect, a core mission statement that I'm sure he believes and any company would be proud of.  He loves making stuff that looks great and is easy to use and, sure, Apple makes a bunch of money along the way.  Seriously, every company could adopt that strategy tomorrow, be more successful and the world would be a better place.  But, again, the tone was just wrong.  I believed it, but he sounded tired and defensive.  He rambled.  When you say you love your customers, when you are stating your core values, make it a love song.

Oddly, the best moment was at the beginning, showing the goofy YouTube clip somebody had posted the night before.  It was sweet, silly and not produced by Apple.  It was funny and, by itself, said things that needed saying.  Showing it made Apple look smart, hip and alert.  The rest of the presentation should have done the same.

Steve Jobs, at his best, is the Thomas Edison of our time.  I don't think I've said anything here that he doesn't know himself.  But he was not at his best on this particular day and we can learn from that.

Location, Location, Location

In theory, location apps are all the rage.  Mostly because a friend was excited about them, I decided to try a couple, Foursquare and Gowalla.  My first check-in using Foursquare was at my favorite grocery store.  Not trying very hard, my second check-in a few days later was also at my favorite grocery store.  I became mayor.  I'm still mayor.  I now have other mayorships, at places a little more exciting than my grocery store (tho my grocery store is quite exciting), but with about as much effort.

If location apps are all the rage, why am I mayor of anything?  Frankly, I don't get out that much.

So I wonder if location apps really are the next big thing or if this is another Silicon Valley navel gazing fad which either hasn't caught on or will never catch on.  It is sort of fun to check-in to places.  I'm not sure how exciting being mayor is, but okay, i guess that's fun.  And the badges are cute.  And the leaderboards are sort of interesting, though I don't know who any of the people are.  I haven't set up cross-posting because other people have and it just clutters things up.  I haven't built specific app communities because I suspect that I just don't care that this friend just arrived here or there.  Maybe I'd care if they were at my grocery store, of which I dream of being mayor for life, but no, not really.

Maybe this is just a curve though.  After initially finding it annoying, I've gotten accustomed to the chatty familiarity of Facebook.  I thought being better connected to my posse would be vaguely annoying, but, after a bit of judicious pruning, I found I kind of like knowing that this person is thinking this or up to that.  Maybe I can find it in myself to care where they're having pizza right now.

I also wonder if the apps couldn't be easier to use.  Why do I have to explicitly check-in?  Couldn't they auto-check-in?  Oh, yes, I might walk by an adult bookstore, and get checked in under false pretenses (really, false!  I promise!), on the other hand, maybe that would improve my reputation.  I also wonder if this wouldn't be a boon to stalkers who could now follow my every move.  I don't have these kinds of problems, but I wonder why we're so willing to put ankle bracelets on ourselves.

Or maybe it's just nice to know when a friend is having pizza.  Maybe I'd join them.

Agile or Fragile

Criticisms of the Agile methodology range from the complaint that all that iteration is just a lack of planning and organization to the complaint that the Agile process is overbearing, controlling micromanagement.  Which is a bit unfair, the actual Agile Manifesto 12 principles is reasonable.  The problem is software engineers like rules, like process, like some external authority that validates what they do, so Agile becomes the next silver bullet.

What's Good

If you have a team that's large, doesn't communicate well and is led by people who are either inexperienced leaders or simply leaders who are spread to thin, Agile may be for you.  Done right, it provides a framework that everyone can understand and live by and a framework that encourages communication.

What's Bad

In a nutshell, people stop thinking and point to the framework as the one true solution to all known problems.  Bad news, the next monsoon will still knock down all the houses in the village, scrum or no scrum.  The rest of this post will be taken up with what's bad, annoying people who have latched onto the Church of Agile and will brook no dissent.

Let's take a look at a few Agile assumptions.

Agile Assumption 1: The Waterfall Methodology is the Enemy

Because it's easier to sell your idea if you have a counter example which sucks, the Waterfall methodology is set up as the enemy.  Agile projects are light and responsive!  Waterfall projects require years of analysis followed by years of implementation followed by unhappy and baffled customers.  Really?  The customers didn't participate in the analysis and implementation?  Sure, if the people running the Waterfall failed miserably to do their jobs.

Let's take a more reasonable contrast: upfront analysis versus a lack of upfront analysis.  Because part of what Agilistas argue is that you don't need to do a lot of upfront analysis.  You ask a few questions, you run off and slam some code, you come back, get your response, go off, slam some code, wash, rinse, repeat.  That's great because you can use that as an excuse to not do the part that nobody likes.  The engineers don't want to talk to the customers because the engineers are nerdy and anti-social (said with love!).  The customers don't much want to talk to the engineers because, well, the engineers really are nerdy and anti-social (said with less love, I'm guessing).  This is convenient for the engineers who can go off and build whatever they want and then be baffled by the unhappy customers.  But they can do it quickly, which the engineers like because they think it's efficient.  The engineers can say, "Hey, it's an iterative process!".  Yes, it is, and it's an iterative process which will never, ever end because the engineers started off doing something they thought would be cool and was in fact way off at the wrong end of the parking lot.

If you do a lengthy (Waterfall!) analysis and the customer ends up with something the don't want, it's not just because the customer is an idiot who can't make up their mind.  It's also because you assumed that the customer knew exactly what they wanted (and the customer assumed that too) and so your "analysis" was to write down whatever the customer said.  Probably not correctly, because it was both boring and more complex than you realized.  Which isn't analysis, it's stenography.  Bad stenography.  Work with the customer, question the assumptions, push back if what they ask for doesn't make sense.  Do analysis.  Go back and look at the Agile principles.  Do they say "don't do analysis"?  No.  You just think they do because you're lazy and don't want to do a good job of analysis because you just want to code so much that you're willing to pass up on the opportunity to do it right the first time.  You will never finish.

Agile Assumption 2: Pair Programming leads to Quality Code

Yes, this is XP, but often the Agilistas will borrow from other methodologies, perhaps without even realizing it.  How is pair programming supposed to work?  Two smart creative people sit down and work collaboratively to solve a problem.  It can work that way, but there are other scenarios.  Strong engineer plus strong engineer - they try to kill each other.  Strong engineer plus weak engineer - the strong engineer carries the weak engineer.  Weak engineer plus weak engineer - crap squared.  I'm all for collaboration, I'm all for code reviews, but if you see a productivity gain from forced, 100%, wall-to-wall pair programming, you have some people who need firing.

Agile Assumption 3: Documentation Is Always Out of Date

Sure, if you don't do your job.  Seriously, what's wrong with you?

Agile Assumption 4: All Teams are Self-Organizing

From the core principles: "The best architectures, requirements, and designs emerge from self-organizing teams."  No empirical evidence, but is sounds damn good, let's go with it.  And where we go is to the underlying assumption: all teams are self-organizing.  They aren't.  There will always be members who just want to show up, sit in their cubes for 8 hours, collect their paychecks and go home.  These people aren't going to step up to the plate and make sure that the architecture is solid, the requirements are thoroughly vetted and the designs well thought out.  There are groups made up of individuals who seriously care and will produce and there are groups made up of individuals who will not fix a bug unless the customer finds it.  The latter is not going to produce the 'best', no matter how much process you hand them.

Conclusion

Agile isn't bad.  Like I said at the beginning, go read the core principles.  Pretty sensible stuff.  Now look at the mountain of nonsense and process and non process that has been piled on top of those principles and don't do any of that.  Agilistas like to claim that if your Agile project failed, it's because you didn't do it right.  Oh, the irony.

As noted above, where Agile can be really useful is projects which involve a number of different groups without good channels of communication coupled with weak management.  By 'weak management' I don't necessarily mean 'bad', it could be that the managers are spread too thinly to be effective coordinators or are too junior to have the necessary diplomatic skills to make a large project work.  Agile can provide a useful framework and add a little spine where it might otherwise be lacking.  The team also has to be good, you can't make a silk purse out of a sow's ear.

Like any silver bullet, Agile only kills the werewolf for which it was designed and often not even that one.  Use it when it makes sense, not when it seems like the cool thing to do.

Oh look, somebody smarter than I am wrote a better article.

Concision v. Clarity

Recently, the reinvigorated programmer blog ran a series, "Why ___ is not my favourite programming language".  He covered C++, Perl, Javascript, C, Ruby and Java and posts were basically excerpts from standard manuals that, in most cases, demonstrated aspects of the language which allowed the incautious programmer to easily write buggy code.  The charm was that these weren't obscure byways in the languages, these were main thoroughfares.  A very funny series.

The series ends with a post on what his current favourite language is and his argument is quite interesting.  Basically, he comes down to choosing between Java and Ruby and goes with Ruby, preferring it's concision.  Usually, the concision argument is pretty easy to mock because all too often concise == inscrutable, but it's worth going over and looking at his pro-concision bullet points, it's the best defense of concision I've seen.  He spoils his point a bit with a Java v. Ruby example where the Java example could have been much cleaner, but still, point taken.  Newsflash, Java isn't an especially concise language.

I don't know Ruby and I'm not writing this post to defend Java, but I would like to make one small point in Java's favor.  Java (and Pascal) are verbose, strict languages.  The nice thing about this is they tend to be self documenting and they don't let you make a lot of stupid mistakes.  How often did I write

if ( a = b )

in C?  Often enough so that I got really good at recognizing the symptoms of the mistake and finding it quickly.  Java won't let you do that at all and saves a lot of time because of it.  Back when the comparison was relevant, I used to say that a project could be done in C more quickly, but the same project done in Pascal would be more robust and require less maintenance and would cost less in the long run.

This is the foundation of my "downside of concision" argument.  You may be able to accomplish more with less, but how maintainable is it?  Many years ago, I was maintaining some chunk of legacy code and ran across a line that looked like this:

<var> <var> <var> <var>

Hmmm.  Wonder what that does?  The manual was no help - where are you going to look?  There's no syntax there to go to the index with.  After some spelunking on my own, I was able to determine that the first variable seemed to contain a file name and after knocking on the doors of several senior developers I finally found one who vaguely remembered what it did.  This was 20 years ago, so I'm sure I'm not remembering exactly, but the upshot was something like: var 1 is a file, var 2 is a column in the file, var 3 is a pattern.  Do a binary search on the file in the column for the pattern and put the line number in var 4.  Admirably concise!

My point is this.  The language is only part of the problem.  Being able to write it quickly and, later, being able to read it quickly isn't the same as being able to understand it quickly.  Any line of code that you write, you should ask yourself, when I come back to this in 6 months, am I going to know immediately what it does?  If yes, one gold star.  The next question is, can somebody else come up to this line of code and immediately know what it does?  Two gold stars!  For three gold stars: can somebody who isn't that familiar with the language look at the code and know immediately what it does?  A very high bar indeed.  Some languages help you write easily understood code more than others, some languages fight you every step of the way (I'm looking at you, Perl).  If the language works to obscure your intent, verbosity and comments are allies.  In the end, clarity is the programmer's responsibility.

TMI

Too much information. Hours of Tivo. Subscribed to a bunch of blogs in all my areas of interest. Too many areas of interest. Boxes of CDs to listen to, drives full of music files to listen to. Books on shelves, books in boxes, books in storage. Magazines by the bagful. Social networks! Podcasts! The cherry on top: Netflix.

Filtering must be the answer, except it isn't. I want the variety, I want the challenge, I want the flood of data points large and small, obscure and exciting, thorny and fun. I want the poem of the day, I want the policy debate, I want the low comedy and the high art. Smarter channels might help, but a well organized flood is still a flood.

What i really miss is a quiet moment to contemplate a work of art. More than a moment. I want to wallow. Listen, carefully, to Beethoven and Feldman. Read, carefully, Whitman and Tolstoy. Sit for an hour in front of a Turner. The list goes on, and that's the problem. I need a 50 hour day.

The first impulse is to take advantage of the wealth of options. Then you realize you can't, there are too many options. So you look for a way to more efficiently pack all the possibilities in. Anything else would be compromise! Compromise is for the weak! You don't want to limit yourself!

Maybe you do. You can't do everything. That's not weakness, that's not laziness. That's realistic.

I accept that. No, not really, but I will. Choice isn't for the weak, it's the greater discipline!

But what will I choose?

News

Microsoft introduces Windows Phone 7 Series, a complete ground up rebuild and reimagine. Good move, realizing that they needed to rethink and acting on it. The challenge will be delivering from within a corporate culture that is still Windows-centric. This will probably turn out pretty well because Microsoft can make the hard choices when it has to, though not as well as it needs to because there will be a large internal cohort which doesn't realize it has to.

Big Telcos are forming a consortium, the Wholesale Applications Community, to offer unified app store competition for Apple and Android. This will probably fail. First reason - intercorporate politics. Seriously, AT&T, Verizon, China Mobile, NTT and many others are going to present a coherent united front? If you can keep the executives out and only the gearheads in, maybe. Good luck with that. Second reason - not a lot of money in it. Apple is believed to be breaking even on the app store and the development community. The real money is the hardware and the real value of the app store is to advance the utility of the hardware. Maybe the phone makers have a motive, some of them are taking a "silent partner" role in the consortium, but they aren't going to work together easily either. The telcos seem to have little motive either. Just being against X, in this case Apple, is not a business plan.

The Not Computer for the Rest of Us

On January 27th, an incredibly important speech was delivered. Sure the State of the Union, but Steve Jobs' unveiling of Apple's worst kept secret, the iPad was the real deal.

The iPad is not a huge leap forward. It's principal advantages over an iTouch are only two, but those two are huge.

• Size. Yes, size matters. I personally have no problem reading 'The Count of Monte Cristo' on my iTouch, but a lot of people are going to be more comfortable reading with more screen real estate. And while a lot of the apps I use on a daily basis are fine on the the iTouch/iPhone and are often likely improved by the focus forced by the constraints of the platform, there are plenty of apps and many web pages that will improve with more room to roam. Reviewing, let alone editing, a spreadsheet on an iTouch? No thank you.
• Typing. This is really size again, but it's a significant functionality improvement. My iTouch has freed me up to travel without a laptop and still keep in touch, but essays and longer emails wait for a keyboard. The iPad keyboard will take some getting used to and will start out with a bunch of bad press, but trackpads took some getting used to and started out with a bunch of bad press too. The iPad looks like it's going to be a little bit bigger than something I'd like to carry around, but choosing between it and my laptop for most trips is going to be a no-brainer. And I'll still have the iTouch in my pocket for walking around. The iPad will have an optional keyboard, but having bought the optional keyboard for my Newton and then only using it once or twice, I'll be skipping it this time.

There are a number of criticisms leveled at the iPad.

• Tablets have been around for years and made little impact. Trying to cram the existing PC/Windows experience into a tablet doesn't get you to the "tipping point". What it gets you is a device that isn't a very good PC. Apple's iPhone OS reimagines the UI and scales up to a tablet better than Windows will ever scale down to a tablet. Throw in iWork, redesigned for the iPad, and 140K existing iPhone/iTouch applications plus the web and web based applications and you've got a tool that's tough to beat. Amazon's Kindle certainly won't, it's price point may be lower and they'll be adding apps, but they've been thoroughly leapfrogged.
• The iPad isn't "open". Linux fans remain puzzled by the failure of Linux to take over the universe. It's free! It's open! It's massively configurable! Yes, it is. And 1% of the universe cares, if that. In the early '90s, I spent several hours helping a long time Apple employee set up an .Xdefaults file on his swanky sun workstation while he looked on in stunned disbelief. Being able to open up the hood is great, but most people don't want to do that, they just want to read their email and look at Facebook and then get on with their day. I only care that Android is Linux if, for some reason, I want to do "chmod 4777" on my phone. Few do.
• Corporate IT hates it. Of course they do, that's their job. Their job is also to figure out how to make it work if there is a business or productivity case.
• It's not really a computer. I don't imagine I'll be busting out Eclipse and cranking any code on it any time soon, but, for now, that's not what it's for.

An interesting thing about most of these comments - they've been leveled at Apple forever. The Mac isn't open, corporate IT hates it and it isn't a "real" computer. Bust out of your box, maybe the computer for the rest of us is just a device that, without a lot of fuss, does a lot of useful things.

Tongue extracted from cheek, how is a product announcement on par with the State of the Union? Because if the iPad is successful, it will cause cultural shift, the way the first PC did, the way the web did, the way cell phones did, the way laptops did. It will put the web, your books, your music, your work, your recreation all in your pocket for a relatively low price. It will succeed where others failed because it goes that one last mile and becomes a device for the rest of us.

And I Ran...

The woods are lovely, dark and deep.
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.

I recently read "Ultramarathon Man" by Dean Kamazes. I understood this guy completely - I'd run marathons myself. Not physical ones, marathons of the mind.

Once upon a time, I was the hero coder. The guy who was there in the morning when you came into work, the guy who was there in the evening when you left. I was King of the Critical Path. You couldn't have a meeting without me, you couldn't ship without my parts being done. I worked seven days a week, sixteen, seventeen, eighteen hours a day.

This didn't happen all at once. Like a marathoner, I had to train. I took on multiple jobs. I volunteered for the software equivalent of suicide missions. If nobody else could figure out how to do something, I was the guy who got the project. In the beginning, I took sundays off. If I tried to work seven days a week, I fell apart on day ten.

I loved the work. I loved the mental gymnastics of it. I loved thinking about a problem and the tools I had to solve the problem and how to coax the tools into doing what I needed. A giant puzzle, everything connected.

I'm a pretty bright guy, but I'm not necessarily the smartest guy in the room. I've been lucky that way, learning a lot from people who knew more. I also worked hard not just to keep up with people who were smarter than me, but ideally to stay a step or two ahead.

I loved being this guy. I got really good at being him. I was well paid. I also was also overweight, lived on colas, potato chips and asprin. I don't need a lot of sleep, but everybody needs more than the hour or two that I got. People guessing my age were off by years and not in a good way.

Reading "UltraMarathon Man", I could see myself. This guy ran from Sonoma to Santa Cruz. This is my home territory, I know how long it takes to drive that. He ran 100 mile marathons. He ran a marthon at the south pole. He trained to endure. I understand that.

One day, I blanked. I was giving a presentation. A two cola presentation, which meant I brought along two colas to help keep myself awake while I was talking. It was morning, who knows how many colas I would consume throughout the day, a day which probably had me leaving the building around 2 a.m. It would take about an hour to get home. I'd probably be back before ten the next morning.

The presentation wasn't going that well really. I was fine, doing the full on mad scientist thing, leading the group through a series of complex abstractions without any notes. They weren't really following. My presentation wasn't bad, but it was difficult material and I was talking non-stop and writing furiously on the white board and they just weren't up to the task of following and I wasn't up to the task of simplifying.

It was a dazzling performance. I was the hero coder.

And then I blanked.

I was exhausted. I was on autopilot. I wrote up on the board: function name. Open paren. Then, nothing.

There should have been a parameter name. Instead, just white space. White space on the white board, white space in my head.

I stood there at the white board, pen not quite touching the surface, waiting for the next token.

Nothing.

I stood there, pen poised, I have no idea for how long. I didn't panic. I didn't think. A little ways into this, one of my collegues said, "Give him a minute, he's really sleep deprived right now." I didn't really understand what she'd said, I just recorded it. And continued to stare at the white void.

The moment passed, finally. I have no idea how long I'd stood there, it seemed like forever. And then suddenly the flow clicked back on and away I went.

But afterwards, thinking about the moment. I wondered what it was I'd really become and decided that was no longer the person I needed to be. I was ready to move on. I could run the marthon, I didn't need to run the marathon. I had run it, further and better than most. It took a long time to change gears. I continued to be hero coder, but I was because I was, not because I tried to be. And now, I'm the next thing.