The countries in Europe have different productivity. Germany is large and near the top, Greece has a lot of debt and is near the bottom in productivity. With an open market and easy credit, the mismatch in productivity produces a trade imbalance within the EU, and that accumulates as debt. Poor Europe buys goods from rich Europe partly on credit.
Assuming things remain constant, this credit is nominal only – it’s to keep trade flowing and will never be repaid. This is usually OK. Sovereign debt is usually permanent, and it’s really a monetary instrument (bonds are a kind of slow money) rather than a cashflow debt that’s expected to be repaid. The market will sustain the debt if it matches the pace of growth, so that the debt to GDP ratio is roughly constant. If debt grows much faster than GDP the market gets jumpy and starts perceiving sovereign debt as ordinary cashflow debt, and we get the current mess.
What, then, is to be done? Europe as a whole has three options:
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.