The current pricing model for air travel is nonsense stacked upon nonsense. Single fares, return fares, fees for changes, discounted and flexi fares, business fares, loyalty bonuses… all nonsense. It developed as an anti-competitive arms race between the airlines of the 70s and escalated from there. Nonsense. Here’s how to price air travel properly.
The cost of a seat has three components:
- A fare, valid for a segment class, season, and class of service. For example “Between UK and East Coast US, standard service (economy), spring-summer 2014” £345.
- An option to travel on a particular date, flight, and seat. For example “Option to travel on VS45, LHR-JFK, May 17, 2014, rows 28-37” £73.
- An efficiency bonus. For example “Returning within a week, returning on the same weekday, checked baggage, full flight” -£65 (discount). Or another example “Short connection, Roll-on luggage, meal” £35 (surcharge).
To travel, you need to purchase a fare and at least one option for the flight you want. When you check in you may get money back as an efficiency bonus, or if you do certain things you may be asked to pay surcharges.
The cardinal error of design is to survey your users, observe what they do, gather your use cases, understand the use cases in detail, and then design your artifact to embody each of those use cases as directly and faithfully as possible. It’s to design your artifact explicitly according to the way it’s supposed to be used.
Wait, what? Isn’t this how you are supposed to do design?
It’s not. People will not use your system the way you designed it to be used. It’s a mistake to assume it will be used one way, or five different ways, or as many ways as you’ve explicitly enumerated. However many distinct use cases or paths you identify, people will use it in more ways. They’ll use it their way. They’ll combine different ways and jump between one use case and another. Or they’ll interpose a different product in the middle of using yours. A well-designed product accepts that actual use patterns are emergent. You cannot list them, but you can hope to facilitate as many patterns as possible beyond the ones you’ve envisaged.
After years of leading software projects I’ve learned many good practices about tracking issues. The most surprising and important though, is this:
Each of your issue tickets is costing you a fortune. Keep their number down!
And I don’t mean the engineering cost of the actual fix. No. The mere fact that a ticket exists in your tracking system is a gigantic time sink. Continue reading
Here’s what I learned about requirements management after more than 15 years in the medical software industry.
Stop! Before you invest any time or money on requirements management, or any tools for that, you must solve these three problems. No, really! Don’t work on processes or tools until you fix these:
- Give your dev team a very clear, straightforward, down to earth picture of what you’re trying to build. You should be able to explain it in an hour and write it in a few pages. This must come from marketing, but everyone in the team should be able to relay it faithfully enough.
- Make sure everyone in the team actually believes this is happening! Check that they believe the project is going to take place, the time scale is sensible, it’s going to succeed, and that they personally are going to do it. If they don’t really believe some of that they’ll keep working, but won’t achieve success.
- Make it so that your people care personally about the product and its quality. If you’re building a consumer app like a game or website, make sure they use it. If it’s a profesional tool make sure they empathise with the specialist who is going to use it, and what the specialist is trying to achieve in the world.
The good news is, once you solve these three issues thoroughly, requirements management will be very easy. All you need is descriptions and categories. A document with chapters will do. If your project is large or has a long future (and not otherwise) use a database that gives you at least one level of nesting, so you can group related specs (user interface, back end, service & support, etc) together. That’s all you need. Write specs as simple facts about what the product does.
It’s time to have one operating system, and it will be Android. Yes, on everything. Google’s world domination will succeed.
There are two sets of things an OS does. It’s a user interface, app sandbox, and hardware abstraction. Android does these really, really well. It’s a fresh UI for fingers rather than mice. It’s the first to offer proper sandboxed security, so we can install apps written by random strangers, like we wanted to do since the 80s. It runs on everything and it’s free.
The other job of an OS is to be a deployment target for apps. A few years ago, the bulk and complexity of these APIs ensured the dominance of Windows. Now, the lock is breaking. Software is becoming a service. You don’t buy software, you download the app to access the service, or it’s just a Web page. Legacy software like Microsoft Office can run in VMs, or in the cloud.
Note, this is a fairly superficial rant. Don’t tell me that it isn’t an in-depth analysis of the transport industry, I know!
Air travel is stuck in the 1960s. Not the planes. The planes have evolved greatly but the airlines, the service offering, and the experience are stuck in the ’60s
Why do airlines still exist? Or rather why are the plane operators still so visible to the customer? Buying travel from an airline is like buying energy directly from a company that runs power stations.
Running planes is, for all practical purposes, a commodity service. Safety is governed by regulations and the economics are better the fewer and larger the planes. Aviation would be better run by commodity carriers.