Wabewalker

The iPad detractors in a nutshell:

The iPad is designed for stupid people. Stupid parents will buy it for their smart children who will not reach their full potential and instead grow up stupid.

The iPad defenders in a nutshell:

We just want something that we can use, and that doesn’t make us stupid. Computers aren’t supposed to challenge users.

Both sides have valid points.

Detractors:

Yes, you have a point. The iPad isn’t designed to educate; there’s no easy ramp-up from user to developer. Parents may erroneously believe it is a substitute for a proper computer, and for those with children without the desire or talent to develop software they will be right. For those with children beyond their intellect level, they will be horribly, horribly wrong. Sad.

Defenders:

Yes, you have a point. Computers are obnoxiously difficult, and for the vast majority of people they are unnecessarily flexible and thus overly complex.

Here’s some advice from your Uncle Wabe which will piss off each side equally:

Detractors:

Give up. You’ll never convince the vast majority of the web because they don’t care. They don’t want to hear about slaughterhouses or butchers; they just want to eat hamburgers. Most computers are ridiculously overpowered and unnecessarily flexible for 99.44% of the population, and anything that eliminates said complexity is a godsend. Parents ruining their children’s future through ignorance has been the norm for centuries; don’t blame Apple for their minute contribution to that tragedy.

Defenders:

Remember that somebody has to develop iPad 2. If it isn’t going to be your children, your children will be cleaning the bathrooms of the children that do. Accept the fact that it isn’t a learning tool, that it’s more akin to a television than a computer. All those kids developing iPad apps? They learned their craft on a real computer. Claiming otherwise is just dogmatic and rightly earns you the label of “fanboy.”

In short, get it into the home and keep it out of the schools. Now, that wasn’t so difficult, was it?

Addendum: The other thing that is ticking me off: the unending comparison to the automobile. If you are trying to argue that the introduction of the iPad is a watershed moment that is destined to bring a renaissance to computers, do you really want to compare it to a sclerotic technology which last saw innovation with Henry Ford?

location: United States, California, San Francisco

mood: annoyed

My head hurt after the debut of the iPad. Aside from being thoroughly underwhelmed, something inside was complaining loudly, complaining that Apple was slowly moving away from where they should be. It gnawed at me for days until I could finally put it into words: the iPad is for dumb people.

OK, maybe “dumb” is too strong a word. Let’s use “passive” instead: it is designed for the passive consumption of media and the passive use of software by passive people. It is the replacement for the television that Steve Jobs has vocally decried in the past. If you are an intelligent, creative, mentally active person then you should find yourself slightly annoyed by its arrival.

“You go to your TV set when you want to turn your brain off. You go to your computer when you want to turn your brain on.” — Steve Jobs

Substitute “iPad” for “TV set” and you have the state of affairs today.

I have been a long Apple booster; going as far back to the dark days when the company faced oblivion. I have always believed that Apple put thinkers before drones; that the appeal of their products came from an intrinsic ability to “get out of the way” until needed (in Heideggerian philosophy, “ready-to-hand”). This appeal was often regarded as elitism by those outside the ecosystem. Maybe it was.

This history gives perspective to the event. The iPad is a step backward: back to the System 7 days when it cost significant money and effort just to write a toy program on the Mac, because the Mac wasn’t for development. This strategy worked for a while: Apple sold a lot of copies of MPW when people still considered the Mac worthy for development; but they kept charging outrageously even as the OS slipped further into obscurity. MacOS X was a major departure from this model: the entire development suite — compilers, IDE, et al. — was shipped with the OS, gratis. It explains the initial appeal of the system to the technology-minded.

The iPad has 80% of the functionality of a regular laptop. The problem is I use that missing 20% a lot more than the rest. If it is missing from the system, I can use Automator or AppleScript or even Perl to complete my workflow with minimal fuss. That missing ability is why the iPad does not appeal to me at all, not even as a dumb terminal. I am lazy and demanding; I will gravitate away from platforms that require too much manual work to get the output just as I want it, not how it wants it.

But the key word in the above paragraph is “I”. I am not a normal user. I work very hard to be lazy. Most people won’t bother setting up complex workflows once: they will blithely view repetitive tasks as bothersome but necessary. Most people will be quite happy with the output of iWork as-is, and be ecstatic that they are no longer held hostage by an overly complex graphical interface. Most people can sit down, do their work, and spit it out — unperturbed that it looks exactly like everyone else’s. The iPad will sell well because there are a lot more garbagemen than college professors.

Maybe “dumb” is the right word after all: the voiceless masses that use the Internet not to share their insight but to consume a surfeit of mindless entertainment. If you really want to have a voice, the iPad is not for you. I’m pretty sure Apple realizes that; the problem is that they just don’t care. Professors don’t make profit.

As I said, I’m annoyed; but not worried. The annoyance comes from Apple-the-supportive-creative-company moving slowly but inexorably towards Apple-the-restrictive-publishing-house and taking important resources with it. The annoyance comes from the blogging drones claiming that the iPad is the best thing Apple has ever produced and that if you don’t like it you’re shortsighted. The annoyance comes from the idiot analysts claiming that the iPad will finally kill off the Mac. The day for worry is when Apple announces that they’ve ported XCode to Windows.

(Edit: Changed post title to better reflect point of this article)

Damnation. This kind of fanatical “activism” is what makes it a pain to own a Mac. Yeah, yeah: you sabotaged a Microsoft ad campaign. Woo. I bet you feel really proud.

Dorks, the lot of ’em.

location: United States, California, San Francisco

mood: cranky

Paul Graham is whining about the App Store. It’s the whine du jour amongst the blogerati: the review process is broken, developers will flee, the ecology will disintegrate without a constant stream of new applications, the sky will fall, humans will be sacrificed, dogs and cats will live together. You know the drill.

I am sure no one, not even the most loyal employee inside Apple, believes the App Store review process is even near perfect. There are human beings involved and subjective decisions required: mistakes will be made.

So, why should Paul care enough to post?

Simple: the App Store review process throws a big ol’ monkey wrench into the grinding gears of his beloved development process. The key paragraph:

Apparently Apple's attitude is that developers should be more careful when they submit a new version to the App Store. They would say that. But powerful as they are, they're not powerful enough to turn back the evolution of technology. Programmers don't use launch-fast-and-iterate out of laziness. They use it because it yields the best results. By obstructing that process, Apple is making them do bad work, and programmers hate that as much as Apple would.

Paul’s obviously a big fan of the Agile movement. But let’s face some ugly truths:

• Agile is not about quality.
  Agile is not about efficiency.
  Agile is about power.

  The micro-bureaucrat née programmer has never had much control over his life. The deploy-first-deploy-often model cuts the unpleasant QA step out of the development process, which gives the programmer direct power over the end user. A QA department can criticize him, can have his sorry ass fired; all the beta mob can do is whine and beg for updates.

• The review phase is not going to produce bad work.
  The review phase is going to produce work free from unnecessary and untested features.

  This is what programmers hate the most: being forced to work on things that are not fun. That’s 90% of the reason for software bloat: that there is no oversight, no adult to warn about losing an eye. Either the manager of a project is technical, or he is not. If the manager is an ex-programmer, he hates having to manage. He does not want to alienate the developers: he wants to be their friend. A non-technical manager can afford to be aloof, but his lack of technical knowledge allows him to be easily snowed. A technically skilled manager who is able to say “no” is a rare bird indeed.

  Iteration is impossible here: the developer gets one shot, and if he screws it up then the reviews will be mostly negative and his little application will fall off the bottom of the list. Apps for the iPhone may be delivered via the web, but they are still shrink-wrapped software: the rules are different from web-based applications.

• Apple is not going to lose the best developers.
  Apple is going to lose the rockstar programmers.

  Apple is going to lose the programmers that blog, that twitter, that whine, that post to Slashdot and Stack Overflow. Apple is going to lose those Internet celebrities whose sole purpose is to dribble fame onto the nameless hordes that adore them. These are people that have to produce a constant stream of updates lest they lose the spotlight to which they are desperately addicted. Apple will be far better off once they move to the next big thing.

• Apple understands software.
  Apple understands that software is not about the means it is produced.
  Apple understands that software is about the user.

  Granted, they’ve made mistakes in the past. But what we’re seeing is an observer effect: the developers who whine about the review process are the ones who were rejected for an absurd reason. Nobody is going to blog about how they were shot down legitimately. Nobody ever admits culpability: not Apple, not the developer, no one.

• Apple doesn’t give a damn about making life easier for programmers.
  Apple makes life easier for customers.

  One way to appeal to programmers is with software. If you could think of an application programmers had to have, but that would be impossible in the circumscribed world of the iPhone, you could presumably get them to switch.

  This is the same myth that has led Linux, despite its power and economy, to fail time and time again in being the desktop of choice. It does not understand the common man; it is built by developers for developers to develop with and upon. Eric Raymond can blog until he’s blue in the face about how nigh impossible Linux is for the non-technical user, but it falls on deaf ears. Simplicity isn’t fun.

People are whining because Apple is succeeding despite constant predictions that it was destined to fail because Apple does not follow the arbitrary rules set by the “developer community.” Just as the Windows crowd complains that the support Apple receives from its customers is merely from a cult of personality, just as the Cluetrain people gnash their teeth because Apple has huge mindshare despite never holding a “conversation” with their customers, the Agile proponents are livid because Apple is succeeding despite ignoring every tenet of their beloved manifesto.

You can’t argue with success. And in the end, the best developers — the steady, responsible, modest, trustworthy developers — simply demand renumeration for their work. And that, alas, is exactly what the App Store will give them.

Engadget: OpenOfficeMouse isn't free, isn't pretty

Eighteen buttons. Eighteen friggin’ buttons! Good God.

That mouse epitomizes one of the more gratuitous mistakes of the open source movement: overly complicated to the point of being completely unusable. The idea “if X is good, then two of X must be great!” is far too prevalent in the geek consciousness. Complicated messes turn normal people off. Sorry, nerds: my mom loves her single-button Mac mouse, and she’s not alone.

This product should have been aborted in the concept stage. Everyone who greenlighted that monstrosity should be banished to a remote island so that horrors like this are never repeated.

Using Cobertura within a NetBeans project is not that difficult, but there are a few subtleties that I often miss. This setup will use Cobertura if the library is part of the test classpath; otherwise, it will silently skip the instrumentation step. For shared development environments, developers that do not wish to instrument will have to create an empty Cobertura library to avoid the dreaded “Missing Reference” problem.

The majority of the heavy lifting is done within build.xml. After NetBeans has set up Ant with its own macros, check to see if the Cobertura library is installed, then load the Cobertura Ant tasks:

<!-- If the Cobertura library has been added to the classpath and it is the right library, set the flag -->
<target name="-check-cobertura-availability" if="libs.Cobertura.classpath">
<available property="cobertura.available"
    classname="net.sourceforge.cobertura.coveragedata.HasBeenInstrumented"
    classpath="${javac.test.classpath}"/>
</target>

<!-- Load in the Cobertura tasks and set runtime properties to reasonable values -->
<target name="-load-cobertura-tasks" if="cobertura.available">
<taskdef classpath="${libs.Cobertura.classpath}" resource="tasks.properties"/>
<property name="test-sys-prop.net.sourceforge.cobertura.datafile" value="${build.dir}/test/cobertura.ser"/>
<property name="build.test.coverage.dir" value="${build.dir}/test/coverage"/>
</target>

<target name="-post-init" depends="-check-cobertura-availability,-load-cobertura-tasks"/>

The following step is annoying, but it helps insure that stale instrumented classes do not shadow fresh compiles:

<!-- Flush all previously instrumented code -->
<target name="-pre-compile">
<delete dir="${build.test.classes.dir}"/>
</target>
<target name="-pre-compile-single">
<delete dir="${build.test.classes.dir}"/>
</target>

This is the most important step. Since we are interested in instrumenting the application classes but do not want to ship instrumented code, we need to dump the instrumented class files somewhere else instead of using Cobertura’s default behavior to modify in situ. Since NetBeans complains if classpath directories are missing at start time (“Missing Reference”), it is best to dump them in a known location. The test build directory is a perfect candidate:

<!-- Instrument the application code -->
<target name="-pre-compile-test" if="cobertura.available">
<delete file="${test-sys-prop.net.sourceforge.cobertura.datafile}"/>
<cobertura-instrument todir="${build.test.classes.dir}"
    datafile="${test-sys-prop.net.sourceforge.cobertura.datafile}">
    <fileset dir="${build.classes.dir}">
	<include name="**/*.class"/>
	<!-- any classes that will not be exercised ("too simple to test") should be listed here -->
    </fileset>
</cobertura-instrument>
</target>

There is still an issue here: by default, NetBeans searches the classpath used to build tests before it searches the test build directory. This means that the default behavior is that the test runner will load the non-instrumented application classes instead of the instrumented ones. Changing the search order for running tests in the project properties solves this problem, but will not affect developers running tests without instrumentation.

Finally, generate a human-readable report (and a test report as well):

<!-- Produce the coverage report -->
<target name="-cobertura-report" if="cobertura.available">
<cobertura-report srcdir="${src.dir}" destdir="${build.test.coverage.dir}"
    datafile="${test-sys-prop.net.sourceforge.cobertura.datafile}"/>
</target>

<!-- Produce the coverage and JUnit test reports -->
<target name="-post-test-run" depends="-cobertura-report">
<junitreport todir="${build.test.results.dir}">
    <fileset dir="${build.test.results.dir}">
	<include name="**/TEST-*.xml"/>
    </fileset>
    <report format="frames" todir="${build.test.results.dir}"/>
</junitreport>
</target>

Happy happy joy joy: now test coverage reports will be generated for those that care, and silently skipped for those who don’t.

location: United States, California, San Francisco

mood: working

IF Comp ’09. Ulcers on standby.

location: United States, California, San Francisco

mood: cranky

“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”

Haven’t kvetched in a while, but then I haven’t had anything to kvetch about. (This will change once I start judging IFComp ’09 next week.)

After doing some accidental research, I’ve come across a set of new anti-patterns that are bothering me:

Design-by-ferret

We’ve all come across systems like this before. The older section follows one convention, and the newer section follows a different and completely incongruous convention.

These architectural chimeras are the result of a lack of systemwide vision: the senior engineer is unwilling (or unable) to enforce a unified vision on the project so his bored subordinates adopt the latest sparkling technology no matter how inapposite. You can tell the age of such a project by cutting through the various layers: this was implemented when Spring was in style, that was written when Rails was the rage.

Design-by-anecdote

Almost the exact opposite of the above: sticking to an outdated model because a single incident found that a standard technology was of dubious quality.

Type-style blending

Some people prefer to have the compiler catch their errors early; others prefer to have the flexibility of a dynamically typed language. Who can confidently say which is better?

I can. There is no reasonable justification for leaving potential errors to be caught at the time of execution, and a properly designed system will make sure types represent the semantic usage of the variables.

Religious arguments aside, the one thing everyone should agree on is that while they both have their trade-offs, no good can result when the two models are blended in a single system: you get the instability of a dynamically typed language with all the overhead of a statically typed one.

Type-style blending is another unpleasant byproduct of an architectural chimera.

Over-reliance on legacy

When nobody really understands the code, the oldest sections take on a formidable sacrosanctity: they are so important and so convoluted that no one dare touch them lest the entire system irrevocably collapse. Newer features have to link into the legacy core even if they could be written efficiently with more modern techniques.

I once had to inject code before every call of a core function rather than adding it to the core function itself because the core had been written by developers who were no longer with the company.

Same signature, duplicate code

This fallout from cargo-cult programming is from misunderstanding overloaded functions. The functions have similar implementation but only differ on the number or types of arguments. Rather than deem the most-specific variant as authoritative, the same code with only minor changes is cut-and-pasted. That’s the fast track to misery right there.

Trivial one-use methods

The extreme opposite: simple operations that are wrapped up in opaque methods just because you can. Usually the result of overaggressive refactoring, but can also result from a misguided attempt to make the code more literate. Trust me: x + y is much more readable than addIntegers(x, y).

I sometimes refer to this as Hilfinger’s Syndrome, but usually get blank stares when I say that.

Management-by-ferret

This is when a manager (usually an over-promoted engineer) grafts a development process onto a project that was built without one. The graft is usually one from the XP family, and it is more often than not only tokenisticly followed. It’s an instance of the general problem of cargo-cult management: adopting a development process because of the belief that going through the ritual will somehow magically make development easier.

Untestable requirements

Untestable requirements lead to unintelligible code which leads to unfulfilling results. Like logical inference, the consequences are disturbing: even horrifically bad code satisfies untestable requirements (noted succinctly by William Wimberly).

TDD on untestable code

You can’t write unit tests for code that was not designed to be tested: code that is tightly coupled, is dependent on external resources, or in general is opaque and intractable. If the code is untestable, safe refactoring is impossible.

Unit tests that test the entire system

These are not unit tests, and calling them such will not magically make them unit tests. A unit test by its very name tests a unit of code: a method, a single path through a module, a simple state transition.

Rockstar developers

This isn’t really an anti-pattern; more like an annoying trend. I have seen far too many job requirements containing the phrase “rockstar developers only.”

Do you really want rockstars? Do you really want prima donnas that will storm out if you do not have a bowl of green M&Ms on their desk every morning? Rockstar developers have rockstar egos and rockstar demands. When they become irreplaceable, you end up working for them.

I’m cranky and demanding. Does that automatically make me a rockstar developer?

location: San Jose, CA

mood: apathetic

I’m annoyed but not surprised about the multiple geekgasms bubbling through the digerati about Google’s pre-pre-announcement of their new operating system, Chrome OS. As I’ve said before, there is nothing a blogger likes more than a tech company catfight, and pitting Microsoft against Google is a classic.

Still, I’m betting on Microsoft to win this in the long run. Not because I think Google don’t have the technical skill; they do, of course. What they lack is the technical vision to pull it off. The whole premise of Chrome OS is that there is enough functionality on the ol’ Interweb to eliminate the need for local applications. Yeah, right: ask Steve Jobs how well “web apps are a sweet solution” worked out for iPhone 1.0.

Hell, I’d be willing to bet that Chrome will never see the light of day outside of the Googleplex. The powers that be will quietly knife the baby rather than release something that will be a mockery of usability. Just using gOS — supposedly based on Google’s own internal distro — is painful: all the glitz of the Macintosh experience without the ease of use. (The idea of “Spray-on Usability” runs rampant throughout it.) In the second half of 2010, a few blogs will post “Whatever happened to Chrome OS?” but that will be it.

Google’s up to something, all right; but radically redefining the idea of an operating system is not it. Maybe they’re trying to kill the netbook market with something that will leave a bad taste in everyone’s mouth.

mood: contemplative

Dan Lyons:

Cook is a great manager, a whiz when it comes to managing supply chains and keeping the trains running on time. He is vital to Apple. Jobs cannot do what he does. But neither can Cook do what Jobs does. The fact is, Apple needs both of them. Forgive me for the analogy I am about to make — but if you’ve seen the latest Star Trek movie, then you might understand how Cook and Jobs work together. Cook is Spock: low-key, cerebral, methodical. He’s the Apollonian counterpart to Kirk, the Dionysian hothead. Kirk is impulsive—but nobody would deny that he, not Spock, should be captain of the ship.

(via Daring Fireball)

No advice for the heir to the throne from me: if anything, my suggestions for products are things not to do. I’m a technophile, a nerd: but unlike my fellow geeks, I am sufficiently self-aware of my detachment from mainstream society to realize that anything I do would appeal to a very narrow subset of the population. (That’s a pretty good razor right there: a nerd realizes he is out-of-touch with reality; a geek doesn’t.)

No, I want to look at the article itself.

Lyons pretty much has said what others were scared to admit. What I found odd about his article was that he danced around his thesis without explicitly stating it: Apple is doomed without Jobs at the helm. Granted, he has always been a Cassandra as far as Apple is concerned, but this time he has a valid point. I can think of only four possible scenarios that can happen after Steve Jobs leaves the CEO seat: two good, one iffy, and one disastrous.

• Apple hires from within. This is the most plausible: Tim Cook is practically CEO right now in everything but name. It would be the least disruptive choice.

  Unfortunately, as Lyons pointed out, Tim Cook is not a visionary. He is, however, the one that the board of directors and institutional stockholders find most comfortable: soft-spoken, hard-working, and rational. That’s the problem with the current suite of CxOs at Apple: they have reached their position by compromise and concession.

  Let’s face it: Jobs wouldn’t even be CEO if he hadn’t founded the company. People like him end up bitter and alone at the bottom of the pile — I speak from experience. When you are that arrogant, the only way you get to the top is to start there.

  Prognosis: stasis or slow decline.

• Apple hires from without. This could happen even if Tim Cook takes the CEO position: one disastrous quarter and the institutional investors start panicking.

  This would kill off Apple’s lead the fastest. There are no executives out there with the kind of artistic vision the position requires (sorry, Ellison — apes do read philosophy, they just don’t understand it). Any outsider taking the position would inevitably try to change the company’s style. Any change to the working environment would lead to a mass exodus of talent.

  Prognosis: a quick trip back to the quagmire of the ’90s.

• Jobs anoints a successor, and it is a creative outsider. This would be the most radical action possible: the one that would cause a panic amongst the prosaic industrial investors, mass defections from the current executive stable, and the one that would be the most likely to keep the company at the forefront of the industry.

  The problem is that there really aren’t any creative outsiders out there. Anyone who is notable and talented is stuck to the surface of Bubble 2.0 and shows no indication of leaving.

  Prognosis: stormy weather ahead, but ultimately a continuation of Apple’s status as a vanguard of consumer technology.

• The CEO position is filled via a “reverse takeover” like what happened with NeXT. This could happen if Apple starts to slip and Cook decides that the only way to regain mindshare is to snap up a hot young company. The problem is that the current collection of hot young companies are led by people with less fiscal sense than a teenager with her father’s stolen credit card at the shopping mall during a fashion blowout. Say what you want, but Jobs has never entered a market without having an idea of how to make a business out of it.

  Of course, this could lead to another “dynamic duo” like the relationship of Jobs and Cook as described by Lyons (really, Dan: Star Trek? Of all the “buddy movies” to pick…). But people are funny creatures: when they get kicked down the corporate totem pole, they start looking for other opportunities. Cook (or someone like him) would have to retain the CEO title but be boss in name only.

  Prognosis: good, but only if the reverse takeover results in an executive cadre that supports its leader fanatically.

What Lyons is trying to say is that Apple needs to continue its success post-Jobs with another Steve Jobs. Best of luck with that. The problem with trying to find another is that the search requires the kind of radical thinking that only Jobs seems to have.

But hey, you have my résumé. Feel free to call.