Wabewalker

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.

location: Home

mood: amused

I normally hate these things, but this one caught my fancy and the result met my approval:

Pretty much sums up the entire conversation, actually.

First thoughts on the Safari 4 Beta:

• Top Sites/Coverflow History. Very nice. This feature is very similar to the one that debuted in OmniWeb a while back. I almost considered paying for OmniWeb for that feature alone, but that they had forked WebKit to maintain otherwise private APIs made me very nervous about long-term support. This’ll probably be a stake in the heart of OmniWeb.

• Tabs in Title Bar. Eh, I can take it or leave it. At first I hated it, because I thought it would really confuse new users. The title bar is the name of the document being viewed or edited, period. But then I realized that the whole concept of tabs blew that metaphor straight out of the water: it introduces multiple documents into a single window. Mac users may laugh at the concept of MDI, but it looks more and more like applications are returning to that model.

  How I would have preferred it: The Mac UI already has a metaphor for manipulating multiple documents at the system level: it is called the Dock. If it were me, I would have changed the tab bar to a dock-like entity, supporting hiding, magnification, and positioning on the window. Either that, or toss the Dock in 10.6 and replace it with a global application tab bar under the systemwide menu. Keep things consistent. (I don’t know why I bother: Apple engineers are bound and determined to pimpify the UI to Vista levels of unusability.)

• WebKit and Nitro. <rant>Somebody please tell me why, after four releases, Safari/WebKit won’t support the CSS2 “quotes” property that has been in the spec since 1998. That’s right, a whole bloody decade ago. I realize corporate pressure means that WebKit extensions that enhance the iPhone and Dashboard come first, but really. Less time dealing with Acid3 corner cases and more time on basic functionality, please?</rant>

  How I would have preferred it: Actually working. (If I could get WebKit to build on my machine, I’d fix it myself. But the Makefile assumes all paths are sans whitespace and I’m loathe to rename my drives.)

Addendum: Called it. OmniWeb is now free (and abandonware).

location: Home

mood: elated

I’m out as of Wednesday. (Take the subject of this note any way you want.)

The company is desperate enough to avoid bad press that they’re willing to part with two extra months’ of salary per employee if we keep quiet about the internal goings-on. That’s something I can live with. As far as I am concerned, this will be the last time I ever mention Yahoo again.

Because if you’re not allowed to say something not nice, you might as well say nothing at all.

Jerry is out. Whoo.

Excuse me for not having an orgasm. This is non-news for two reasons: 1) it was expected; and 2) it will change nothing.

Jerry is the Herbert Hoover of Yahoo: he is not responsible for the collapse, but he did little to prevent it. His policies at the end were pretty much “status quo, only ever so much more so.” The company was psychotic from the Semel years, and will pretty much remain so until the rest of the Semelites ablate.

But before Yahoo can recover, it has to show humility. It has to accept that it is not, and has never been, a technology company. Nor is it a media company. It is a distributor, a syndicate, of content from both users and professional publishers. Semel couldn’t accept the fact that he wasn’t an entertainment mogul; Yang couldn’t accept the fact that he wasn’t an engineering genius.

It’s funny how some companies maintain the original personalities of their founders long after the founders have faded into the background. Google was founded by two computer science students based on a data mining algorithm they developed at Stanford; today, Google still thinks in terms of solving problems via engineering. Yahoo was formed by two students who gathered an inexplicable following for their web page of links to content they neither produced nor owned; today, Yahoo is best at managing content and maintaining a community. Microsoft, well… avarice is what best describes them: claw your way to the top via acquisitions and outright theft.

People fear Google, and rightfully so. They see another Microsoft on the horizon: a company that will so dominate the landscape that innovation will all but cease, as it did in the early ’90s. The thing that bothers me is, why put your faith in a company that has shown time and time again that it is not to be trusted? There are far safer ways to keep Google in check than to give Microsoft a ten-year extension to its monopoly.

What started out pathetic ended pretty well. Three games were close enough to perfect to earn the coveted “10” score:

Magic

A parlour magician with PTSD battles killer bunnies.

Nightfall

London has been evacuated. Figure out why and stop a disaster.

Violet

Try to avoid distractions while you write your thesis. (A lot better than what its premise suggests.)

Links and notes:

IF Comp 2008 Reviews

The furries have invaded. I repeat, the furries have invaded. Last year, elf slash; this year, werewolf sex.

…is the freetards on Slashdot latched onto Stallman’s dick. Seriously, skinning? Not a killer feature. It’s fun for about three minutes after you download the Lost-themed skin, install it for LOLs, then find it unusable and revert to the default. Always use the Mom test: would your mom be willing to use the feature without assistance from you? I didn’t think so either.

In any case, bundled and free beats out downloadable and free every time. Just ask Netscape.

The embedded clip in this story is hysterical: the Fox reporters use every possible euphemism for “stupid” without actually saying Sara Palin is. “Looking at 2012”? Riiiiiight.

It’s a bad time to be a Neo-Con.

I feel their pain: I supported Jerry Yang at the beginning; now I think he’s a coward. I’m willing to admit to bad judgement. Why can’t they?

(As usual, I do not speak for Yahoo!)

Sue Decker:

Yahoo! continually optimizes its algorithmic and sponsored search, and we have, in 2008 alone, developed and launched hundreds of improvements all designed to enhance search quality…

“Hundreds of improvements” is always a bad sign: it implies that: a) the original design was poor; or b) each improvement is a rapid response to a corner case, which in turn weakens the overall structure; or both. Painting over cracks does not eliminate the cracks; it only makes it more surprising when everything collapses.

Ultimately, this decision will be the end of Yahoo! as an independent entity. The Justice Department’s tacit anti-trust policy for the last eight years has been one of establishing lopsided duopolies. Internally, the JD assumed (incorrectly) that Microsoft was the only US business that could keep Google in check. As long as Ballmer remains in charge, Microsoft cannot even keep itself in check.

Selling to Microsoft is not the only option open to Jerry Yang et al. If he were really courageous, he could try to greenmail the Justice Department itself: simply state that if the government does not subsidize Yahoo!, Yahoo! will shut down its search operations and tell its users to go to Google. As I have said countless times before: Yahoo! is not in the business of competing with Google; Yahoo! is in the business of making money. Yang has to remind the Justice Department that it is their job, not his, to keep monopolies under control.

location: Home

mood: contemplative

I take back my original criticism of “The Slaughterhouse” as being weak sauce. Of all the mazes, it's the one that still spooks me over a week later. Why?

It was the first maze that Knott’s Halloween Haunt has done that had a living (well, animatronic) victim.

Almost all of the characters in the mazes can be broken down into two groups: living monsters and dead victims. There are corpses galore and gore aplenty, but you don't see anybody in the process of being murdered. It all happened in the past. Even “Quarantine” showed only the consequences of insanity, not the insanity itself.

“The Slaughterhouse” was different. For the first time in my memory, they had a victim screaming for help as he was barbequed alive. It changed the maze-goers from simple crime-scene voyeurs to callous, indifferent accessories to mayhem. We visitors went from horror-movie patrons to pedestrians who ignore the bleeding man on the curb.

I’m sure it was intentional, possibly an experiment to test the limits of what the public will find acceptable. The big question: will that thrashing victim be a prop next year, or will too many people be as disturbed by it as I was?

location: Home

mood: exhausted

So, yeah. IF Comp 2008. Lookin’ bad, lookin’ real bad.

Why do I do this to myself every year?