When Elon Musk announced that he wanted to plant a colony of 80,000 people on Mars in his lifetime, a few thoughts went through my head in (roughly) this order:

• That’s an awfully long supply chain if things go wrong
• Somebody is going to be responsible for administering the whole thing
• That has to be the toughest job in history
• They’ll need to be solar-class experts in many areas, or able to learn them in a hurry
• There ought to be a handbook for this sort of thing

Obviously, it would more closely resemble a library, rather than a “For Dummies” type book.

Equally obviously, there would be a large team responsible, with many kinds of experts engaged in their own particular specialties.

Somebody would ultimately be responsible though.

Call them the CEO. Or the First Mayor of Mars. That person will need to have at least some understanding of each of the different subject areas of their team. Continue reading →

The following series of ideas occurred to me while holding a loose thread on my jacket, and trying to decide whether to try breaking it on the spot, or to wait until I had a pair of scissors handy.

The manufacturing of clothing is still largely a low tech industry (unlike the making of the fabric itself), where rooms of poorly paid workers cut and sew together garments (I’ve linked to some articles below, some of which have great photos showing what a modern sweatshop looks like). Continue reading →

I’ve been fascinated for a few years now with cheap 3D printers like the RepRap and MakerBot Replicator. One of the issues with these printers is that they can only create relatively small items. I believe that a relatively small change to how they are constructed could help with that. Continue reading →

The usual disclaimers apply: I can’t tell whether this thought is original, the technology isn’t quite there yet, and I’ve only done a partial economic analysis.

In the near future, many people are likely to have 3d printers in their homes. These printers will likely only be used on occasion. The installation of software similar to the [email protected] project could allow these printers to be utilized during downtime for mass production of small products, in exchange for payment to the printer’s owners.

Continue reading →

Lots of speculation that Facebook is going to try (again) to build a mobile phone. I understand why they feel this is necessary – they’re already losing ad revenue due to people accessing the site via mobile apps – but as many others have commented, this is unlikely to work (and could cost them billions of dollars in the process).

Here’s a simple alternate plan for how they could win mobile revenue, and create a mobile platform, without building any hardware:

1. Extend their existing mobile app so that it allows users to run existing Facebook applications from within it.

2. Create new tools to allow app developers to take advantage of this capability. Creating mobile apps is still a lot of hard work, and walled gardens like iOS make it hard for developers, so a clean, cross-browser-compatible, Facebook app-based mobile platform could really help developers. Plus if its cleanly integrated into the mobile app, there’s no reason why users who are already utilizing it won’t adopt it as well.

3. Build out their existing ad network to target these new capabilities.

The above would be a lot of hard work, but IMHO it would have a much better chance of success, and would cost a fraction of what they would spend buying up hardware companies. Plus it plays well to their existing strength in platform development.

Update: Actually, I can think of one strategic reason why Facebook would want to get into the phone business, although I’m not certain that it is sufficient. If such a phone contained near field payment technology, then Facebook Credits could be used at the “final mile”. Such an approach would probably imply the purchase of a company like Square.

This is the third and final part of the series. If you haven’t read the other parts, you can find them here and here. The following is a heavily edited version of an internal document that I wrote a number of years ago to try to standardize internal web development. Continue reading →

If you haven’t read part one, this is a highly edited version of an internal document, on the topic of creating a company standard for html, css and javascript work, with some of the (justified) language toned down.

Part 1 of the post may be found here.

Continue reading →

Again with the CEO? Seriously Yahoo!?

Whenever I’ve spoke with former Yahoo! employees in the past few years, the overriding theme seems to be anger and disappointment. One does not feel emotional in this way about a company that cannot achieve; it is the mismanagement, lost opportunities and loss of direction of a team that used to consider itself a world-leader that results in such a temperament.

The question remains though, regardless of what happens in the near-term with their current CEO. Can (or should) Yahoo! be turned around, or should it be torn apart and sold for scrap? Continue reading →

The following post(s) are edited from a document that I wrote a few years ago to try and provide a consistent standard for HTML and CSS submitted by contractors for projects that my company was working on. At the time we found that we were spending a significant chunk of time on rework, in order to make things function properly across different browser types, and the goal was to reduce this, and simultaneously improve quality and customer satisfaction. I’ve edited things a bit, as the original was written with a sarcastic (and occasionally profane) tone that is slightly embarrassing in retrospect (although entirely necessary at the time). Continue reading →

It seems like a strange idea – that people can build things that are so complex that they no longer understand them fully. It is more common in the realm of large projects where thousands of people work together on a single goal (think of the Space Shuttle, with its millions of moving parts), but it also happens on occasion in software development.

I can think of a handful of projects that I have worked on that have reached this point. One in particular, although the number of lines of code is not exceptionally large, has so many moving parts that it is actually impossible to determine in advance what effect any given change will have on its operation. Modifying its core functionality becomes a delicate game of trial and error. Continue reading →