Better is the enemy of best

You might have heard the aphorism “Perfect is the enemy of good“.  If you’re in a technical field, you’ve probably used it, or had it used against you, to shut down a conversation.  It’s an effective way to do so because it insinuates that the target is thinking impractically, not focused on the problem at hand, rat-holing or bike-shedding or yak-shaving or otherwise getting distracted from “getting shit done”.  All clearly faults, right?

Its original wording, “better is the enemy of good”, more clearly reflects its defeatist mentality that presumes things can’t be much, if any, better than they are now – always implied as the aforementioned ‘good’.  It’s often taken to its extreme – unintentionally ironically – as part of perfect solution fallacies – that it must be impossible to achieve perfection, so why even try?

It can be very difficult to rebut because in practice it’s somewhat subjective & contextual, and thus judged in the context of the dominant culture – which in tech, currently, is pervasively biased towards doing things.  Not necessarily the right things – just things.  Move fast and break things.

Further challenging the defence is that it’s often considered ‘above my pay grade’ to think about the bigger picture.  Especially down where the rubber meets the road and people have deadlines and quotas and (believe they) are judged solely by the volume of work they complete.  In that environment, targeting someone with that aphorism is labelling them as being disruptive, slowing things down, and not having their priorities in order.  A would-be tall poppy.  A Troublemaker™.

In short, it puts the target on the defensive for an indefensible position – and makes it personal, no less.  It is, in a way, a nuclear option – the conversation abruptly ends with no actual conclusion, and no problems actually addressed.

It is in fact a clever ruse, and while usually used well-meaningly rather than viciously & tactically, either way it’s usually used unfairly, inappropriately, and worst of all, incorrectly.

Amongst its many flaws, in practice if not in logic, I believe its worst is that it conflates the path of least resistance with the right path.

Building a better horse.

It is a pervasive practice within business to look at where you are now and where you can go from there.  This is called incremental planning.  An instrument & exemplar of this mentality is SWOT analysis.  In a nutshell:  what have I got going for me, what’s going against me, and how can I work with that against my immediate environment?

It is supposed to be applied tactically.  When misused as a strategy, it does so predicated on the belief that by incrementally improving along the path of least resistance – i.e. opportunistically – one will inevitably triumph above all others.

That is the kind of thinking which leads to building a better horse, rather than realising you can build a car instead.

It is applying the process of finding your local maximum, in ignorance to finding bigger maxima.  It is short-sighted and tunnel-visioned and preys on our lizard brain’s desire for constant gratification and reassurance that we’re making forward progress.

In a competitive environment it is guaranteed fatal, because sooner or later one of your competitors will find a bigger maximum.  Or worse, someone from outside your market entirely, not so constrained in their thinking, will come in and set up shop on the slopes of a much bigger maximum to begin with.  Ever heard of an ‘iPhone’?

Of course, not all tech environments actually have competition.  If you’re working on a company-internal product, yours is usually the only one within your company.  You have a captive market with zero competition.  So unfortunately, you’re free to produce bad products indefinitely, at least insofar as they’re not so bad that they bring down the whole company.  And for as long as you can convince your bosses that you’re working really hard and it’s a really hard problem and look at how big these closed bug numbers are.

Thankfully, there are other motivations – than market dominance or conservation – for building better things.  Some people have an innate desire to do so.

Where are you going?

The incremental planning approach leaves it to a higher power to determine if you’re even heading in the right direction.  It is by definition short-sighted, putting emphasis on speed and not direction.  It is dangerously optimistic.

If you don’t know where you’re going, you might not get there.

Yogi Berra

Incremental development is not the problem.  It is not at odds with vision & leadership.  It is just all too often confused with, and entangled with, incremental planning.

You cannot know where you should be going if you don’t know what the possibilities are, and specifically what the best possibilities are.  Once you’ve identified them, only then can you investigate how to get to them – and thus in what direction you need to move.

Thus why the first step in any kind of development – technical, business, or otherwise – must be to identify where you want to be, irrespective of where you are currently.  That in itself is a complicated task – full of whats and whys – but given that, then you figure out how you might get there.  With that map and route in hand, then you act on that, and only then do you turn your focus to speed – to execution.

And this is where “Perfect is the enemy of good” actually comes in, in its correct usage.  What you identify as the highest place to be might be very difficult to reach from where you are now.  Perhaps there is a different place that’s nearly as high, but much easier to get to.  That might offer the best return on investment, and thus be the best solution.  Especially if it gets you closer to the highest place as well – what you cannot do today, you might be able to do tomorrow.

You must, in effect, put the car before the horse.  If you do not currently possess the means to build a car, find a way of building better horses that gets you closer to building a car, so you at least have a chance of building cars in the future.

[Mechanical Horse patent image used under CC BY 2.0 license from Patents Wall Art on Flickr – available as real wall art through their Etsy store.]

‘Fake error’ about immutable values when using popFirst() on Array

It’s been a while since I wrote any meaningful Swift.  How I didn’t miss the Swift compiler’s bullshit error messages.

var someArray = ["Foo", "Bar"]

if let foo = someArray.popFirst() {
    print("Who cares, we never get here anyway.")
}

That yields, on the popFirst() method:  “Cannot use mutating member on immutable value: ‘someArray’ is immutable”.

No it’s not.  It’s simply not.

For whatever reason, if you instead call popFirst() on ArraySlice – ostensibly indistinguishable from a real Array – it works just fine.

var someArray = ["Foo", "Bar"][0...]

if let foo = someArray.popFirst() {
    print("Yet this works correctly.")
}

Sigh.

I presume it’s trying to tell me something stupidly obscure about Swift’s byzantine type system.  Good luck finding out what.  Good luck even finding the definition of the popFirst() method, since Xcode claims it doesn’t exist if you Command-Control-click on it.  But Xcode can’t find most things, so that in itself says very little.

Things you find googling yourself

In no particular order.

  • The Hotline File Transfer Protocol v1.1.1.  I presume I was interested in, or actively doing, a third party Hotline client.  I did tend to make lots of data transfer clients back then (e.g. HTTP, FTP, even POP3 & SMTP).
  • My little gallery of childhood toys & memorabilia.  I hadn’t forgotten about this per se, but it’d certainly been a long time since I’d look at it.  In hindsight I’m really glad I took the time to take these photos – most of this stuff is long gone now, so the photos are all the remains to pique my nostalgia.
  • Apparently I discovered some ‘fix’ for Apple breaking dial-up modems in a Mac OS X Jaguar (10.2.4) update.  I vaguely recall that, though I’m pretty sure that’s not the only time I’ve had to fix stupid regressions in Mac OS X by reinstalling frameworks, kexts, etc from a prior OS build.  Sigh.
  • I’m listed in the National Park Foundation’s 2015 donor list.  I’m also in the 2016 one too, though it doesn’t show up in a web search [yet], and expect to be in the 2017 one as well.
  • Steven Troughton-Smith gives a call out to me (among others) in his little SceneKit demo program and his pretty impressive “OpenWorldTest” (i.e. Minecraft tech demo clone).  I don’t recall have any specific contribution, but way back when Steven & I did chat a bunch about SceneKit, and other topics.
    • It tickles me now, though I haven’t talked to Steven much in years, that his name appears increasingly often in pretty high profile places (e.g. the ATP podcast mentions him almost every episode lately).  He’s certainly made a name for himself.
    • Someone called “Taka Taka” has also run with OpenWorldTest a bit, to add VR support among other things.  Nothing to do with me any more than Steven’s original version – I mention it just because it’s cool.
  • I’m cited in the USF Maritime Law Journal (alas a broken link as I write).  Yep, I’m a big mover & shaker in the legal circle… which is to say, Marisa had an article published there and thanked me for supporting her as she wrote it. 😉
  • In reference to my hacking on CoreGraphicsServices, Nat! (no other name given, as far as I can see) wrote a journal entry about how some people in the Apple community can be, well, wet towels.
  • A bajillion years ago I wrote the Keychain Framework, a relatively clean ‘Cocoa’ (Objective-C & Foundation) framework that wrapped Apple’s C-based libraries for keychain access & basic security functionality (which is in turn an implementation & based on the CDSA ‘standard’ that nobody but Apple appears to have ever actually implemented).  Anyway, apparently it’s used in SQLEditor.  I’m pretty stoked – I sunk a spectacular amount of time into that framework, for very dubious benefit in hindsight. 😕
  • And another old pet project that shows up is my Mailcash plug-in for Apple Mail.  This was an implementation of Hashcash, which I still think is a neat idea for reducing email spam, by making senders ‘pay’ for every email like a virtual stamp.  I have no idea if anyone ever really adopted it, nor if my Apple Mail plug-in still works at all.  Presumably not – I recall Apple Mail breaking plug-ins repeatedly over the last ten years or so, since I wrote Mailcash.
    • Oh how easy it is to date an open-source project when it’s still hosted on Sourceforge.  Poor, sad, lost-its-way Sourceforge.

Curiously, there’s several other open-source projects of mine on Sourceforge that don’t show up in a web search for my name:

  • Build Installer, a template for software installers that build the software from source on the user’s machine – assuming they’ve installed Apple’s developer tools, that is.  From memory this was inspired by the tedious and error-prone nature of various open-source projects, w.r.t. how they distributed & installed their software on Mac OS X.  Sadly, nothing much has changed – there’s now brew & such package managers, but in my experience they make just as a big a mess as doing it manually & ad-hoc did.
  • DePC, a tool for stripping files of those nasty DOS-based file extensions, and instead setting the files’ type & creator codes correctly.  Sigh… I lost that battle.  To this day I still think that was a bad choice, that Apple made, to cave in to file extensions.  They’re still ugly and error-prone.
  • Mission to the ISS, the horrible group project I did with various folks in university, for the CSE32PRO (3rd-year Computer Science Project) class.  Back in 2004, I’d guess, based on the open-source release being in January 2005.  That was a fun project in many ways, though the end result was a bit embarrassing – we ran out of time, during the class, to actually finish it properly, so for example the underlying algorithms that control the simulation are fundamentally step-based, but are stepped every time the user provides any input, so high user interaction makes the simulation run faster than intended, with silly and sometimes outright broken results.  Sad panda.