Archive for the ‘Uncategorized’ Category


The Inversion

August 9, 2011

So Matt Neuberg over at the outstanding Apple news site TidBITS, has written an article about the new OSX Lion application management regime called “Lion is a Quitter.” His basic complaint is that Lion can (with the support of an app) shut an app down, preserving it’s state for a fast relaunch, if that app has no visible windows and isn’t used for a certain period of time. This takes an element of control that he used to have over applications out of his hands and gives it to the operating system to do, in line with what he terms the new “nanny state” attitude of Lion generally.

To the extent to which I can also be an anal control freak, I sympathize with his argument. He’s missing the big picture however, when he says that Apple has enacted this change in order to make OSX more like iOS. The reason for changes like this runs much deeper than that.

Those of us who have put substantial investments into learning all the nitty gritty of how computers work on the inside are quite accustomed to a world where the users are strangers in a specialists’ world. The thing that makes Apple the most radical and successful company in the technology industry is that they think that paradigm should be inverted.

Apple thinks that power users should be the ones who have to work uphill and that regular users should have clear sailing, rather than the other way around. This is the attitude which subconsciously turns engineers and technology geeks and journalists against them. Apple isn’t trying to make life easier for people who do things from the Terminal, they’re trying to make life easier for people who wouldn’t know how to use the terminal.

In the drooling infancy of GUI multitasking operating systems, a set of invisible lists was made. In one column was the list of things the user interacted with directly, and in another column the things that were handled transparently by the operating system. The organization of the file system, process management, versioning, installation, uninstallation and updating of applications were in. Memory management, interrupt locations (and hardware matters generally) were typically out. This mix was largely determined by the computing resources available to the operating system and by extension, it’s capacity to make informed decisions in the matters at hand. Despite an almost embarrassing multiplication of hardware resources however, that mix hasn’t changed substantially in decades. Oh yes, here and there have seen tiny improvements, but overall, the sort  of things you had to explain to somebody who’d never used a computer before haven’t really changed much.

Apple’s list of things a regular user should be interacting with is much shorter. The reason for this is simple; users aren’t using computers to interact with the file system, launch and close applications, keep track of file revisions, or update applications. Normal users are at a computer to get things done, either for enjoyment or for work. Nobody gets paid to manipulate the file system or launch and close applications and nobody does it for love. We do these things because they are the complications and obstacles between us and the actual task we are attempting to complete. Apple thinks they can take most of those intermediate steps away, or replace them with something which is more intuitive and faster to use.

This is precisely as it should be. Performing easy tasks with a computer should be easy, and performing complex tasks should be difficult. The typical users outnumber the power users thousands to one, why would you optimize an operating system for a minority use case? The answer to that question is that operating systems are built entirely by the minority in question. Because power users build operating systems, they tend to be built more for those kinds of users than the more common kind.

I think that Apple’s version of The List is the biggest gamble in the history of desktop computing. Apple intends to entirely re-invent what happens when you sit at a computer, to a level where you spend almost no time operating the machine, and almost all the time performing the task you need the machine for.

Apple sees a world where computers are transparent enough to need virtually no training, and where only the people who need to do complex work should have to grok complex concepts. This is an inherently disruptive exercise, and the people most disrupted will be those who have an investment in understanding the underpinnings of computing. That mastery will never be valued in the same way again. The days when geeks imagined that the world would sort itself into a neat technocracy with the most knowledgeable at the top are long gone. If Apple gets their way, this odd technical specialization will be no more or less important than any other specialization.

In short, Mr. Neuberg, get used to it – This is just the beginning.


The Enemy of the Good

August 3, 2011

I’ve pursued programming as a hobby and occasional sideline income for nearly twenty years. Like a skipping stone, I go long distances between needing to do any development, only occasionally dipping into the water. This is not an efficient way to be a programmer, but I’m not a programmer, I’m a renaissance geek – for me programming is a means not an end.

Having to re-learn the current state of the art every so often for a specific project without staying immersed in the development of the technologies involved has given me perspective on a few issues that everyday professional programmers are often too close to see.

Programming is getting harder. 

Because necessity is always the mother of my coding inventions, I typically re-enter the programming world running and with an eye towards finding the fastest route from a blank screen to the (typically not very complicated) application in my head. In the last 10 years especially, I’ve noticed a trend; every time I set out with a newer toolset to build a simple project, it’s harder to do the same simple stuff than the previous time. Each time the tools update, the simple stuff gets harder. It takes more lines of code to do the same job, and the code is more obtuse. Why should this be?

Nearly seven years ago, I developed a data driven website for a friend using the then-new Ruby on Rails platform. Any of you who were involved with Rails at that time remember the original screencast, wherein a functional web application (a blog) was created from a blank screen, right before your eyes, with a handful of very simple code, and in very short order. This was a revolution! Sign me up! Very quickly, I had developed the app, and all was well. A few years later, time came to update the app, and by this time Rails had graduated a whole version number. Maybe it was time to re-work it for the current version, I thought. Since so much had changed, I decided to go to the RoR website and look at the current version of the famous “blog screencast” – It was a complete mess.

Suddenly, creating the same simple web app wasn’t simple anymore. Vast chunks of prepared code were being pasted in to make the demo as quick as the first demo had been typing all the code from scratch. What the hell happened?

The same thing that happened to VisualBasic between 6.0 and VisualBasic.NET -

Some professional programmer decided it needed to be able to be all things to all people and made it so “powerful” that it wasn’t usable anymore.

Programming languages and frameworks are hard to create, so they are written by quite advanced programmers. Advanced programmers are surrounded by advanced programming work in demanding environments, and that makes them want to develop all their tools for that environment. This brings me to my next observation…

Professionals have a distorted definition of Good.

If you ask a typical cross section of professional developers about the two framework/languages I just mentioned (VisualBasic and Ruby on Rails) chances are most of them will tell you they suck. They’ll also say this about Arduino, Fritzing, RealStudio, Processing, Hypercard (Yes, I’m old in computer years) and any other simple tool for doing simple rapid development. They’ve seen how these things are implemented under the hood, they’ll say, and it’s a complete mess! What a horror show they’ll describe; it’s inefficient, lacks power and has poor flexibility.

They’re not wrong exactly, they just don’t live in the same world occupied by the rest of us. The longer you practice programming the better you get at it. The better you get at it the more complex the projects you end up working on. By the time you are a proper professional, you are working to standards which are so different from what rapid development packages are ostensibly made for that there is virtually no resemblance.

What they are really saying is that those tools would suck for what they do all day. Invariably, what they do all day is heavy stuff. Heavy work requires heavy toolchains, and they judge all toolchains by those standards.

But judging rapid development systems by high-end development standards is like judging street cars by race track standards. Yes it lacks hundreds of horsepower and carbon ceramic brakes, but since I use it to buy groceries and haul myself to the office, so what?

Yes, rapid development tools have inefficient implementation, don’t scale well, and can’t do everything but since I’m not developing inertial guidance systems for moon rockets or hosting solutions for, so what?

These “failings” don’t actually matter in most real world applications, for one simple reason:

Most needful applications are simple.

Anybody who’s worked in the white collar world long enough has encountered a variation of the Dire Spreadsheet. You know the kind I mean, the quivering 19 sheet mass of heavy duty formulas and barely literate scripting which Somebody Who Knew Excel created to do (or nearly do) a job that really needed to be done by either a simple database or a simple piece of custom software.

This is the space in which most software for the small and medium business is written (or rather, should be written). The band of problems in between the capabilities of the spreadsheet or scripted-augmented PDF form but beneath proper heavy duty enterprise development is where the vast majority of the need for custom software exists in the business world. Moreover, for every Dire Spreadsheet or Really Bad Access Database that attempts to fill one of those voids, there are a dozen more companies who simply give repetitive data processing and storage work to human beings with pens and paper forms or perpetually updated word processing documents. Tens of billions of dollars in productivity are lost to this “Undeveloped Band” every year.

These applications-in-potentiâ are child’s play by serious programming standards. They’re so simple, in fact, that there’s no money in creating them even for single independent developers.  With a simple language and development tools, the businesses themselves could plug these holes with perfectly serviceable software. Those tools are thin on the ground, because programming tools are made by professional programmers with professional expectations to match. Institutions without full time developers can’t meet the technical barriers of entry to tools designed for full time programmers and they can’t afford to hire the folks who can. This brings us to the final point :

Most needful software never gets developed at all. 

The promise of the computer in the workplace is largely stillborn. Every day, in nearly every enterprise, people waste human resources on problems that computers are better at solving, all for lack of customized software solutions.

Somewhere, a younger man or woman than I should be looking to solve this problem. They should be looking to turn the Undeveloped Band into a fortune, and a changed world. They should be looking to put software development into the hands of non professionals in the same way that layout was put into the hands of non professionals by desktop publishing.

I hope I get to see it.


Why Washington Can’t Cut Spending

May 11, 2011


Great straightforward explanation of the entitlement trap from the folks at LearnLiberty.


Hello world.

April 26, 2011

Pardon the dust. I’m building the site at the moment. Tune in later and it will actually work and not look terrible. Honest.