It's time for a new measure of growth because, in a world with globalisation - where much of the money you spend goes to another country - GDP is incompetent.
GDP increasing year on year is supposed to be a good thing, but why do we expect this to happen at all?
Where does all the extra money come from?
It comes from the planets limited supply of raw materials such as its coal, gas, oil, gold, iron and timber.
They're either being mined faster or becoming more precious because of their increased rarity.
It comes from the planets renewable materials, for example making water drinkable or generating electricity from wind and solar power.
(And, by the way it makes sense - if for no other reason than long term financial gain - for governments to invest in renewable power.)
It comes from farmed goods such as wheat, rice, fish, livestock and timber.
And it comes from the fact that, due to population increase, we are slowly using up all of the inhabitable space on the planet and that's driving
up land value. If you own a chunk of planet, its value is likely to be proportional to the global population.
And that's it, everything else is just inflation and national debt.
If I do a service for you, no value is created, dollars are simply exchanged. No new money enters the international mega-pot.
Governments can't just "make" money without inflation or currency devaluation. And devaluation is just another form of inflation when you consider the global economy as a whole.
Please tell me if I'm totally missing the point of GDP here! Because it seems to me to be a pointless measure of a global border-less macro-economy!
Monday, July 20, 2009
Wednesday, July 01, 2009
10 Questions to ask before Changing your Software
It's been said that modern day software engineering is like gardening in that you're not normally creating something new but maintaining an existing system.
So when gardening - when making changes to your existing codebase - there are several questions to ask:
The best code change is no code change at all - because every code change carries the potential work of a bug fix waiting to happen.
The smaller the code or configuration change, the lower the risk. If it ain't broke, don't fix it.
Are you making the change because your boss thinks it would be a cool new feature? In which case he's your internal customer (this is often the easiest case as it matters less when the requirements aren't completely defined up front).
Or is it that there's a real, paying, external customer who wants something added to their bespoke software package?
Once you know who it is you're developing for, you'll need to know exactly how they plan to interact with the system...
...and what those new UI components should do under the hood.
Will the change affect your software's architecture? Are you just adding a new widget to your GUI, or are you going to rewrite half of the existing code?
You do have a modular codebase right? Yeah? So you'll need to think about which ones need to change, and how.
Will that new widget require its own module, or does the functionality sit naturally in an existing module?
If new modules are needed, what's their public interface and how do they interact with everything else?
How does the software cope when the inevitable happens and the user does something stupid?
Or the robot that you're driving decides to crash into itself?
What happens when the web service that you query falls over because a pop superstar passes away and there's too much web traffic?
As this is a change to existing system, you need two types of test:
1. Regression tests to confirm that the existing system still works.
2. New tests to test the new stuff.
If the software already has an automated test suite you've covered 9.1 already and covering 9.2 should be a doddle.
This is also the place to look our for deficiencies and commonly experienced problems, for instance, if you have a highly multithreaded codebase, how do you make sure that the delta hasn't introduced a deadlock?
Double check that the change you've decided to make really is the best way before touching any code.
What do you think? Is there anything that you disagree with? Or that should be added to this list of gardeners' questions?
So when gardening - when making changes to your existing codebase - there are several questions to ask:
1. Why am I Making the Change?
The best code change is no code change at all - because every code change carries the potential work of a bug fix waiting to happen.
The smaller the code or configuration change, the lower the risk. If it ain't broke, don't fix it.
2. Who is the Customer?
Are you making the change because your boss thinks it would be a cool new feature? In which case he's your internal customer (this is often the easiest case as it matters less when the requirements aren't completely defined up front).
Or is it that there's a real, paying, external customer who wants something added to their bespoke software package?
3. What are the Use Cases?
Once you know who it is you're developing for, you'll need to know exactly how they plan to interact with the system...
4. What are the Detailed Customer Requirements?
...and what those new UI components should do under the hood.
5. How will the Architecture be Affected?
Will the change affect your software's architecture? Are you just adding a new widget to your GUI, or are you going to rewrite half of the existing code?
6. Which Existing Modules need to Change?
You do have a modular codebase right? Yeah? So you'll need to think about which ones need to change, and how.
7. What new Modules are Needed?
Will that new widget require its own module, or does the functionality sit naturally in an existing module?
If new modules are needed, what's their public interface and how do they interact with everything else?
8. How will Errors be Handled?
How does the software cope when the inevitable happens and the user does something stupid?
Or the robot that you're driving decides to crash into itself?
What happens when the web service that you query falls over because a pop superstar passes away and there's too much web traffic?
9. How do we test it all?
As this is a change to existing system, you need two types of test:
1. Regression tests to confirm that the existing system still works.
2. New tests to test the new stuff.
If the software already has an automated test suite you've covered 9.1 already and covering 9.2 should be a doddle.
This is also the place to look our for deficiencies and commonly experienced problems, for instance, if you have a highly multithreaded codebase, how do you make sure that the delta hasn't introduced a deadlock?
10. What are the alternatives?
Double check that the change you've decided to make really is the best way before touching any code.
What do you think? Is there anything that you disagree with? Or that should be added to this list of gardeners' questions?
Subscribe to:
Posts (Atom)
Posts
