The Sullivan Ouster at University of Virginia: a retrospective

The NYTimes features UVA on its Sunday Magazine cover today, reflecting back on the Sullivan ouster and what it means for higher education.

Three months ago, I put together a summary of the best links discussing the ouster as it happened. Today, combined with the NYTimes piece, it’s easy to get a full context and perspective on this story.

Continue reading The Sullivan Ouster at University of Virginia: a retrospective

My old backpack

Ten years ago today, I bought myself a birthday present. It was a Brenthaven Backpack.

At the tender age of 18, I coveted few things. But among the web designers and programmers whose blogs I read regularly and whom I looked up to, this backpack was the ultimate in durability and functionality.

It featured a padded, hardened laptop sleeve that could sustain even a dead drop from ten or fifteen feet. It had padded, adjustable shoulder straps. It was made from a seemingly indestructible material. It had hidden pockets everywhere.

At the time, I didn’t have a laptop — just a desktop computer. It ran Windows and Linux, and I used it mostly for web design and Macromedia Flash programming. Adobe hadn’t bought Macromedia yet.

Notebook computers were generally clunky and underpowered devices — not meant for doing “real work”. But my Dad purchased me a used MacBook Titanium from a friend of his — and I knew this was a true luxury.

Continue reading My old backpack

Progress Tiers: Epic, Story, Task, Step

I realize that for about 10 years now, I’ve been doing project-oriented work — generally, writing software with working software taking shape over the course of months and even years.

I have developed a theory of “progress tiers” in how this work is optimally managed.

Epics are high-level themes of functionality that manifests in software. For example, “E-mail Notifications”. This is too vague to express a specific user feature, but does express an area of strategic importance to the product. For example, it may be that the product is used primarily via the web, that it lacks engagement from some users, and that all users of the system are also active e-mail users. Therefore, it makes sense that the application would generate some e-mail notifications — but, it’s not yet clear which ones are the right ones, how they should look, how frequently they should arrive, etc.

Understanding the priority of Epics helps the team understand its product roadmap and vision, and the strategic context for the functionality they deliver.

Continue reading Progress Tiers: Epic, Story, Task, Step

Cloud GNU: where are you?

This continues an article I wrote nearly three years ago, Common Criticisms of Linux, parsed and analyzed.

In the three years since I wrote that original piece, Linux has grown — albeit slowly — in desktop usage. After nearly 2 years of no growth (2008-2010, lingering around 1% of market), in 2011 Linux saw a significant uptick in desktop adoption (+64% from May 2011 to January 2012). However, Linux’s desktop share still about 1/5 of the share of Apple OS X and 1/50 the share of Microsoft Windows. This despite the fact that Linux continues to dominate Microsoft in the server market.

The proprietary software industry may be filled with vaporware, mediocre software, and heavyweight kludges, but there is certainly also a lot of good stuff that keeps users coming back.

However, I believe the 2011/2012 up-tick in Linux desktop usage reflects a different trend: the increasingly commoditized role that desktop operating systems (and by extension, desktop software) play in an omni-connected world of cloud software.

Why doesn’t Linux run software application X or Y?

For end users, the above was a core complaint for many years (approx. 2000-2009) when evaluating Linux. However, this complaint has faded in the last two years. Let’s reflect on the most common and useful pieces of software on desktop operating systems these days:

Continue reading Cloud GNU: where are you?

The Debian Manifesto

The Debian design process is open to ensure that the system is of the highest quality and that it reflects the needs of the user community. By involving others with a wide range of abilities and backgrounds, Debian is able to be developed in a modular fashion. Its components are of high quality because those with expertise in a certain area are given the opportunity to construct or maintain the individual components of Debian involving that area. Involving others also ensures that valuable suggestions for improvement can be incorporated into the distribution during its development; thus, a distribution is created based on the needs and wants of the users rather than the needs and wants of the constructor. It is very difficult for one individual or small group to anticipate these needs and wants in advance without direct input from others.

This amazing quote from 1994 (!!!) actually models the way I think about software engineering at Parse.ly.

A nice piece of nostalgia on Debian’s 19th birthday.

See also: A Brief History of Debian, The Debian Policy Manual, & The Debian Developers Map.

Digg’ing your own grave

Reddit is a pretty amazing site.

An early “social news” startup, its founders sold it to a large media company in 2006, and rather than what usually happens in that case — the site shutting down or being subsumed by another property — it continued to grow healthily. Now, it’s probably a top-50 web property, and one of the top-10 drivers of traffic to news sites online (according to our own data at Parse.ly).

Digg, on the other hand, is the “also-ran” in this space. Rather than staying fervently focused on its community, it went through a series of redesigns that resulted in traffic attrition and, as recently reported, a final collapse, where Digg was sold for scrap parts to Betaworks.

Continue reading Digg’ing your own grave

Idleness

NYTimes has a good article today about work and idleness, “The Busy Trap”.

Busyness serves as a kind of existential reassurance, a hedge against emptiness; obviously your life cannot possibly be silly or trivial or meaningless if you are so busy, completely booked, in demand every hour of the day.

[…]

Idleness is not just a vacation, an indulgence or a vice; it is as indispensable to the brain as vitamin D is to the body, and deprived of it we suffer a mental affliction as disfiguring as rickets. The space and quiet that idleness provides is a necessary condition for standing back from life and seeing it whole, for making unexpected connections and waiting for the wild summer lightning strikes of inspiration — it is, paradoxically, necessary to getting any work done.

One of the commenters on this story pointed me toward a much older essay by Bertrand Russel, “In Praise of Idleness”.

If, at the end of the war, the scientific organization, which had been created in order to liberate men for fighting and munition work, had been preserved, and the hours of the week had been cut down to four, all would have been well. Instead of that the old chaos was restored, those whose work was demanded were made to work long hours, and the rest were left to starve as unemployed. Why? Because work is a duty, and a man should not receive wages in proportion to what he has produced, but in proportion to his virtue as exemplified by his industry.

[…]

Suppose that, at a given moment, a certain number of people are engaged in the manufacture of pins. They make as many pins as the world needs, working (say) eight hours a day. Someone makes an invention by which the same number of men can make twice as many pins: pins are already so cheap that hardly any more will be bought at a lower price. In a sensible world, everybody concerned in the manufacturing of pins would take to working four hours instead of eight, and everything else would go on as before. But in the actual world this would be thought demoralizing. The men still work eight hours, there are too many pins, some employers go bankrupt, and half the men previously concerned in making pins are thrown out of work. There is, in the end, just as much leisure as on the other plan, but half the men are totally idle while half are still overworked. In this way, it is insured that the unavoidable leisure shall cause misery all round instead of being a universal source of happiness. Can anything more insane be imagined?

[…]

The modern man thinks that everything ought to be done for the sake of something else, and never for its own sake.

[…]

The pleasures of urban populations have become mainly passive: seeing cinemas, watching football matches, listening to the radio, and so on. This results from the fact that their active energies are fully taken up with work; if they had more leisure, they would again enjoy pleasures in which they took an active part.

Each essay is very much worth reading.

Cloud “backups”

We had snapshots enabled on RDS, which meant that there was supposedly a full snapshot every night and then logs of changes for every 5 minutes after that. The idea behind this was that we could restore to within 5 minutes of when the database stopped logging. However, this snapshot and log was inaccessible since EBS/EC2/RDS were down.

from “Getting Fitocracy Back Online”

This has always scared the shit out of me.

The idea that the backup system is part of what I’m paying for in a hosting provider. But then the hosting provider goes down in a bad way, and not only is my app down, but so is my backup. My approach is to be exceedingly paranoid about these providers. One example of this: I always copy important data not just to Amazon S3 for posterity, but also to a plain old NAS sitting in a physical office over which I have dominion. Yes, S3 has ridiculous durability. But, S3 can (and will) go down. Or, someone will one day compromise Amazon’s systems and figure out how to delete my S3 bucket and all the replicas they have of it.

Honestly, I don’t think cloud has simplified any of this stuff. I think it has actually made it worse, because CTOs think they can outsource their architectural decisions to these service providers. As my Dad once said to me: “it’s not what you don’t know that kills you… it’s what you think you know, that just ain’t so.”

UNIX is the kitchen of the software chef

One of my favorite books on cooking is Alice Waters’s “The Art of Simple Food”. In it, there is a section where she describes the necessary equipment for a kitchen that produces resoundingly good food.

This is one of my favorite paragraphs from the book, because it reminds me of software and my philosophy toward software creation.

She opens with:

I am a minimalist in the equipment department.

UNIX is the minimal software development environment. Over time, people have created lots of alternative environments, IDEs (Eclipse), meta-IDEs (JetBrains MPS), and neo-IDEs (Lighttable).

Continue reading UNIX is the kitchen of the software chef