Paul Graham’s essay on tablets referenced a fascinating term I hadn’t heard before: “ephemeralization.” Wikipedia describes it as “the ability of technological advancement to do ‘more and more with less and less until eventually you can do everything with nothing’.”

Like many folks in the startup crowd, I’m a reader of Eric Ries' blog (some links), and I’ve read Steve Blank’s Four Steps to the Epiphany. What I didn’t know is that these guys have joined forces to build a movement they are calling “lean startups.” After attending the Startup Lessons Learned conference last week, I now believe this methodology is on its way to making a major impact on the world of entrepreneurship.

When you hear the term URL, what do you think of? Probably a web address - e.g., a publicly accessible HTML page such as http://google.com/ or http://news.ycombinator.com/. But URLs have a much wider application.

We just don’t write or release software the way we used to. Software isn’t so much built as it is grown. Software isn’t shipped … it’s simply made available by, often literally, the flip of a switch. This is not your father’s software. 21st century development is a seamless path from innovation to release where every phase of development, including release, is happening all the time. Users are on the inside of the firewall in that respect and feedback is constant. If a product isn’t compelling we find out much earlier and it dies in the data center. I fancy these dead products serve to enrich the data center, a digital circle of life where new products are built on the bones of the ones that didn’t make it.

It is very important to trailblaze unknown territory through activities such as mockups, prototyping, and spiking. However, I sometimes find “architect” level people providing no more worth to their team than a whiteboard full of boxes and arrows and a mouthful of hollow words of encouragement (sarcastic quotes explained). What teams need is clear direction on a clear path.

I see video games as a petri dish, a place where the challenges and rewards of the real world are simulated in a simpler, more discrete fashion. Often the challenges faced remind me of the same challenges I face in my work as an entrepreneur. In the spirit of Scott Berkun’s Management lessons from Gears of War 2, I present you three business lessons I’ve learned from video games.

The Programming Quotes Archive has some delicious morsels:

Fast action, or careful planning? Steve Jensen nails it:

Mark Shuttleworth on release cycles:

• Rapid, predictable releases are super for keeping energy high and code evolving cleanly and efficiently, they keep people out of a deathmarch scenario, they tighten things up and they allow for a shakeout of good and bad ideas in a coordinated, managed fashion.
• Big releases are energising too. They are motivational, they make people feel like it’s possible to change anything, they release a lot of creative energy and generate a lot of healthy discussion. But they can be a bit messy, things can break on the way, and that’s a healthy thing.

Crossing the Chasm is my favorite book on business. Its pages are packed with little gems, like this:

Mads Torgersen, language designer for C#, described about his approach to language design his talk at Codemash. I don’t know the first thing about C#, but I did like a point he made regarding how they evaluate possible new features for the language.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Eric Sink shares wisdom on which bugs to fix, and which not to:

1. Make it work.
2. Make it elegant.
3. Make it fast.
4. Make it secure.

In more detail:

• Make it work - Your first pass is a proof, a vertical slice of all the functionality that proves that your idea is going to work in practice. But it’s probably an ugly mass of bailing wire and duct tape, with no error checking, incomplete specs, etc.
• Make it elegant - Now that you know it works (and you have a good grasp of the problem space and the solution), you can take the time to make your code clean, fully speced, with good class names, proper separation of concerns. In short, something that is readable by others, maintainable over time, that will withstand the earthquakes of change.
• Make it fast - Since your code is clear and understandable, you can now set to optimizing critical code paths. Snappy response time is critical to a good user experience.
• Make it secure - Once you’re certain that all the other concerns have been accounted for and you have something that is not going to be subject to major changes, you can audit the entire process and look for vulnerabilities, both in terms of access and abuse.

Joss Whedon gives ten tips for writing screenplays. These words of wisdom can be applied to any creative endeavour - including building software. Try this one, for example:

Like many folks, my early experience with Ruby was largely entwined with Rails. ActiveSupport provies a lot of handy little helpers that are generally useful; and once I got used to having them, I found myself annoyed that they weren’t available in my pure Ruby programs. Like 3.days.ago, or string.blank?.

Planning is priceless, but plans are useless.

From Good to Great by Jim Collins

Changing things tends to shake out your hidden assumptions. Over time, any system - software, process, even social - starts to build cruft in its cracks. When the earthquake hits, a good system withstands it, because its assumptions are sound and well-tested. A poor system crumbles. Embrace the earthquake when it comes, and learn its lessons.

King Corn is an excellent documentary which describes the overproduction of corn in America. At the end, they dig into the question of why this surplus production exists. The summary is: in the first half of the last century, starvation was still a real threat for a substantial portion of the US population. Corn production was thus optimized for one factor: yield. This was a solution to the most pressing problem of the time. Nutrition, taste, and variety aren’t considered important concerns when people are starving to death.

James Golick says that speculating sucks:

Cloud computing is on everyone’s minds, because it offers the promise of infinite horizontal scalability. But to achieve this, we have to change how we build applications.

Programmers tend to overdesign. Rather than building a quick solution that works right now for the specific case, we want to build one that will solve all problems of that type, both now and for all time. Dreaming In Code shows a particularly egregious case of this: the developers spend years building a framework for the app, rather than the app itself. This type of story is quite common. So frequent is this pitfall that the agile methodology mantra for avoiding it if often referred to by its abbreviation: YAGNI (You Aren’t Going To Need It).

The Shaker Design Philosophy, paraphrased nicely by Josh Porter:

Tiny projects keep it new, for sure. It seems to tie in a little bit with proof-driven development and personal projects - in each case, you’re escaping the mental cage of a monolithic, mature product to start something new. (Even if the “something new” is a component that’s going to plug in to said mature product.)

There’s a cycle to building software. First, you furiously write a bunch of code to get something working. It’s complicated, a bit messy, a bit unfocused - but you manage to get it to work, just barely, and then you can start using it. Being used by one or more real users (even if that’s just you, or you and a few others in your workgroup) then provides focus as to which features and functions are the most central.

Programmers generally agree that working iteratively is a good idea. But sometimes, we’ll say: you just can’t. This particular problem has to be done in one big bite; there’s no way to break it down into smaller pieces; we just have to take the plunge.

Michael Easter puts it wonderfully:

Specs (or tests) show that your code works in theory. A running app in production shows that your code works in practice.

In developing the early implementation of Heroku, I stumbled upon an interesting design/development technique: numerous throwaway proof-of-concepts for potential features. Heroku is an unusual product, and many of the features we envisioned were things we weren’t even sure could be accomplished in a reasonable way with current browser technology. Writing these proofs let us explore the problem space without committing to a single product direction or internal architecture too early.