I've been saying it, others have tried it. Check this out:
Mac Plus (1986) wins the comparison in every day tasks against a... Dual-Core AMD 64!
Tuesday, August 21, 2007
Monday, August 20, 2007
A short one
After auditing some of my coworkers' code today, I would like to paraphrase Felix von Leitner:
Program(mer)s get worse much faster than the computers get better.
Program(mer)s get worse much faster than the computers get better.
Sunday, July 29, 2007
Progress v8: Progress is.
[This is my eighth, and final, article on progress. If you want to read the whole story, here is my first article]
This time I'm going to start with a little story, and the conclusion of this part is probably not what you would have expected, either, but that's what life is: a constant surprise package waiting to be opened.
I came to the demo party in Denmark, The Party 97, expecting to see cool things. One of the first cool things that we saw, after all the two thousand PCs and other computers were turned on simultaneously, was a power outage that took both the shiny Christmas decorations outside, the PCs inside, as well as the domestic power supply of half Aars. When the lights came back up and the demos actually started running, the Party Motto displayed by the demos, that originally had been "Batteries not included", was quickly hacked to display "Power not included" by almost every crew.
When I came to Aars I certainly didn't expect that the winner would be Second Reality, just like at Assembly '93 in Finland. It was the same demo, with music, the speech samples, the 3d part... everything. Except, the disk had to be turned over in the middle. Because this time, it wasn't running on a 80486 with 50 MHz, it was running on the Commodore 64, with an 800 KHz, 8-bit CPU, a machine that should, by all standards of measurement, be about 200 times slower than the machine the demo was originally written for.
People's jaws were hanging wide open.
But not all people's. If you read the reviews, you will see that the "old school" C64 crowd wasn't even that impressed. All of the effects have been done on the C64 BETTER at some point. It was the PC crowd that peed their pants for excitement.
And how can the C64 people with their tiny lame machines that can't even multiply in hardware outdo a PC?
Because they had 10 years more practice: the C64 was built in 1982. Read: 10 years of programming practice beats 6 years of hardware evolution.
Does that mean that the all that PC business had been superfluous, and the C64 architecture should have been kept forever? No new standards, no improvements, no changes...?
No, of course not. We could not do the things we do with computers now, if we would have been stuck with a system that doesn't really allow modularity. If the CPUs wouldn't have made the steps to 32 and now 64 bit, if memory sizes wouldn't have grown over the years, if the CPUs didn't have virtual memory management, modern genetics and Google would have been impossible. And by now, PCs are incorporating the design elements that made C64 and AMIGA technically superior back into the design: sound and graphic chips that do their own jobs with little CPU help, shared memory to avoid copying where memory is a constraint, better standards, etc, etc.
But the actual problem that this C64 demo has shown us in 1997 is by now all-pervasive in the entire software industry: nobody, but really nobody has more than a few years of practice using the new systems and frameworks, because the technologies become obsolete within less than two years from the moment of their creation, and everybody is forced to move on.
Remember the times where such a thing as "craftsmen" existed? People like smiths, or even, not quite so long ago, car mechanics, who spent their lifetimes learning how to do their job well. When knowledge evolved, it took generations. The next generation could learn the old things, invent new things, and pass both on to the next.
Today, we cannot afford to. If we only learn one trade, like one programming language, we will be obsolete within five years, max. If you can learn quickly, you won. If you learn slowly but well... well, you're screwed. By the time you have learned your one thing, it is already obsolete. Pass knowledge to your kids? You're kidding! Even the stuff they learn in school is already outdated. They only learn it so they know the theory. How to do things... well, they will have to learn that on the job.
This is, in my opinion, why there is so much bad code out there. Programs that don't work, because their creators have never learned to do their job well, instead having to spend the time to learn yet another new technology that will be obsolete in a year. This is why everybody and their grandfather nowadays think that they can program, because "X is a new technology, so I had as much time to learn it as everybody else out there." People who had never heard of "Product X" or anything similar two years ago, and when they heard of it, didn't understand it properly, are now sold as the top master level consultants for "Product X" by CSC.
What it really tells us, is, there is only that much speed at which progress can take place. There needs to be a balance between invention and expertise. Innovation cannot take place if you don't have any experience with the thing you are trying to innovate. Otherwise you will end up re-inventing the wheel again, and again, and again instead -- because you didn't have enough time to go out there and find out that wheels exist. Or because you are not the first victim of the cycle, and there are so many different wheels to choose from, that it is easier to just invent your own than to go through all the existing specifications.
You see, in the end, progress is its own worst enemy.
This time I'm going to start with a little story, and the conclusion of this part is probably not what you would have expected, either, but that's what life is: a constant surprise package waiting to be opened.
I came to the demo party in Denmark, The Party 97, expecting to see cool things. One of the first cool things that we saw, after all the two thousand PCs and other computers were turned on simultaneously, was a power outage that took both the shiny Christmas decorations outside, the PCs inside, as well as the domestic power supply of half Aars. When the lights came back up and the demos actually started running, the Party Motto displayed by the demos, that originally had been "Batteries not included", was quickly hacked to display "Power not included" by almost every crew.
When I came to Aars I certainly didn't expect that the winner would be Second Reality, just like at Assembly '93 in Finland. It was the same demo, with music, the speech samples, the 3d part... everything. Except, the disk had to be turned over in the middle. Because this time, it wasn't running on a 80486 with 50 MHz, it was running on the Commodore 64, with an 800 KHz, 8-bit CPU, a machine that should, by all standards of measurement, be about 200 times slower than the machine the demo was originally written for.
People's jaws were hanging wide open.
But not all people's. If you read the reviews, you will see that the "old school" C64 crowd wasn't even that impressed. All of the effects have been done on the C64 BETTER at some point. It was the PC crowd that peed their pants for excitement.
And how can the C64 people with their tiny lame machines that can't even multiply in hardware outdo a PC?
Because they had 10 years more practice: the C64 was built in 1982. Read: 10 years of programming practice beats 6 years of hardware evolution.
Does that mean that the all that PC business had been superfluous, and the C64 architecture should have been kept forever? No new standards, no improvements, no changes...?
No, of course not. We could not do the things we do with computers now, if we would have been stuck with a system that doesn't really allow modularity. If the CPUs wouldn't have made the steps to 32 and now 64 bit, if memory sizes wouldn't have grown over the years, if the CPUs didn't have virtual memory management, modern genetics and Google would have been impossible. And by now, PCs are incorporating the design elements that made C64 and AMIGA technically superior back into the design: sound and graphic chips that do their own jobs with little CPU help, shared memory to avoid copying where memory is a constraint, better standards, etc, etc.
But the actual problem that this C64 demo has shown us in 1997 is by now all-pervasive in the entire software industry: nobody, but really nobody has more than a few years of practice using the new systems and frameworks, because the technologies become obsolete within less than two years from the moment of their creation, and everybody is forced to move on.
Remember the times where such a thing as "craftsmen" existed? People like smiths, or even, not quite so long ago, car mechanics, who spent their lifetimes learning how to do their job well. When knowledge evolved, it took generations. The next generation could learn the old things, invent new things, and pass both on to the next.
Today, we cannot afford to. If we only learn one trade, like one programming language, we will be obsolete within five years, max. If you can learn quickly, you won. If you learn slowly but well... well, you're screwed. By the time you have learned your one thing, it is already obsolete. Pass knowledge to your kids? You're kidding! Even the stuff they learn in school is already outdated. They only learn it so they know the theory. How to do things... well, they will have to learn that on the job.
This is, in my opinion, why there is so much bad code out there. Programs that don't work, because their creators have never learned to do their job well, instead having to spend the time to learn yet another new technology that will be obsolete in a year. This is why everybody and their grandfather nowadays think that they can program, because "X is a new technology, so I had as much time to learn it as everybody else out there." People who had never heard of "Product X" or anything similar two years ago, and when they heard of it, didn't understand it properly, are now sold as the top master level consultants for "Product X" by CSC.
What it really tells us, is, there is only that much speed at which progress can take place. There needs to be a balance between invention and expertise. Innovation cannot take place if you don't have any experience with the thing you are trying to innovate. Otherwise you will end up re-inventing the wheel again, and again, and again instead -- because you didn't have enough time to go out there and find out that wheels exist. Or because you are not the first victim of the cycle, and there are so many different wheels to choose from, that it is easier to just invent your own than to go through all the existing specifications.
You see, in the end, progress is its own worst enemy.
Friday, June 22, 2007
Progress v7: So old is good... or is it?
[OK, it has been two weeks again, and this is my seventh article on progress. I have been a little busy, and the progress stuff is really starting to get complicated at this point. But you can always start with my first article ;-]
So in the last episode we have seen that standards are good for you. In fact, the only reason why our technology works, for example, why you are able to read this, is because standards exist.
This is also how science is made: using common standards (of measurement), one theory can be based on another. So the new researchers don't have to go and re-invent all the theories before they finally can start producing original work¹.
So old is good, right? We can build on a foundation happily ever after?
Except, of course, when it is flawed. Then you can either stop when you recognize that your house is going to fall, or build all the way up until it falls apart. The same good practice that allows us to finally build high also allows us to build on errors of others.
Take the science of Astronomy for example. For hundreds of years it could provide us with no insights more useful then astrology, because it was based on the flawed premise -- the Ptolemaic Universe. It was only after Copernicus and Galilei that we started to be able to look into the actual workings of the universe, because they found the fundamental flaw in the theory of the world to that point: the Earth was not the center of the universe.
If not for the Copernicus, would Galileo have ended up observing the laws of motion? Would Newton have formulated the theory of gravitation based on that?
On the other hand... if not for Aristotle and Ptolemy, would somebody have discovered the laws two thousand years earlier?
We'll never know of course. What we do know, is, that about 2250 years ago, a man called Aristachus of Samos had already developed a very modern view of the solar system. It's just, the geocentric model of Aristotle was viewed as a much simpler explanation for why there is no parallax -- why stars don't visibly "wobble" when the earth move around the sun. In Aristotle's model the earth simply didn't move -- and the calculations for the positions of the planets produced results with accurate enough to look right. And thou shalt never change a running system...
This is one example that shows that with too little information, Occam's Razor can be applied both ways.
It also shows, that based on the same data, you can develop one perfectly working model that is also perfectly useless as anything but a working model (some of the modern unification theories come to mind), and another working model from which you can infer additional information about the subject -- extended use, so to say.²
And also, often enough, you don't see which is which until waaaay later.
So, competing theories, competing libraries, competing standards, are good... if and only if there is suspicion that the current system they are competing with is really inadequate and it hampers development.
But the thing is... Even if software people finally agree on standards, even if people actually cooperate instead of developing against each other, even if we all build on the same foundation... we are still shooting at a moving target.
How so? Well... see you in the next episode of the progress wars!
¹:This is why, when somebody says, "I am just as entitled to an opinion about meteorology as scientist X" he is talking BS -- unless, of course, he actually spent as much time studying the theories behind meteorology as scientist X, and has no bias.
A bias might be his conviction, or it might be his boss telling him that whatever the logical answer would be, the answer that will keep his job safe, is the one that his boss wants to hear. Unfortunately, the laws of physics are not political, only the people studying them are. But this is a different topic.
²: Like, for example, an open-source software library: there, I can learn from something other people already invented and thought through before me. If I see enough of that, I can also pick the components that I think are right, and discard the components that I think are wrong. In other words, I can learn.
With closet, err, closed-source code, this is impossible. You can only build on top of it, and hope that the developer really knew what he was doing and made no mistakes that will affect what you are doing.
Kind of like building on ground where you can't check whether it actually is a swamp. In fact, it is illegal for you to check whether it is a swamp, and you have to build on that ground because "everybody else does it". And where the holy creator of the ground thought that investing 20% of the necessary work is good enough.
So in the last episode we have seen that standards are good for you. In fact, the only reason why our technology works, for example, why you are able to read this, is because standards exist.
This is also how science is made: using common standards (of measurement), one theory can be based on another. So the new researchers don't have to go and re-invent all the theories before they finally can start producing original work¹.
So old is good, right? We can build on a foundation happily ever after?
Except, of course, when it is flawed. Then you can either stop when you recognize that your house is going to fall, or build all the way up until it falls apart. The same good practice that allows us to finally build high also allows us to build on errors of others.
Take the science of Astronomy for example. For hundreds of years it could provide us with no insights more useful then astrology, because it was based on the flawed premise -- the Ptolemaic Universe. It was only after Copernicus and Galilei that we started to be able to look into the actual workings of the universe, because they found the fundamental flaw in the theory of the world to that point: the Earth was not the center of the universe.
If not for the Copernicus, would Galileo have ended up observing the laws of motion? Would Newton have formulated the theory of gravitation based on that?
On the other hand... if not for Aristotle and Ptolemy, would somebody have discovered the laws two thousand years earlier?
We'll never know of course. What we do know, is, that about 2250 years ago, a man called Aristachus of Samos had already developed a very modern view of the solar system. It's just, the geocentric model of Aristotle was viewed as a much simpler explanation for why there is no parallax -- why stars don't visibly "wobble" when the earth move around the sun. In Aristotle's model the earth simply didn't move -- and the calculations for the positions of the planets produced results with accurate enough to look right. And thou shalt never change a running system...
This is one example that shows that with too little information, Occam's Razor can be applied both ways.
It also shows, that based on the same data, you can develop one perfectly working model that is also perfectly useless as anything but a working model (some of the modern unification theories come to mind), and another working model from which you can infer additional information about the subject -- extended use, so to say.²
And also, often enough, you don't see which is which until waaaay later.
So, competing theories, competing libraries, competing standards, are good... if and only if there is suspicion that the current system they are competing with is really inadequate and it hampers development.
But the thing is... Even if software people finally agree on standards, even if people actually cooperate instead of developing against each other, even if we all build on the same foundation... we are still shooting at a moving target.
How so? Well... see you in the next episode of the progress wars!
¹:This is why, when somebody says, "I am just as entitled to an opinion about meteorology as scientist X" he is talking BS -- unless, of course, he actually spent as much time studying the theories behind meteorology as scientist X, and has no bias.
A bias might be his conviction, or it might be his boss telling him that whatever the logical answer would be, the answer that will keep his job safe, is the one that his boss wants to hear. Unfortunately, the laws of physics are not political, only the people studying them are. But this is a different topic.
²: Like, for example, an open-source software library: there, I can learn from something other people already invented and thought through before me. If I see enough of that, I can also pick the components that I think are right, and discard the components that I think are wrong. In other words, I can learn.
With closet, err, closed-source code, this is impossible. You can only build on top of it, and hope that the developer really knew what he was doing and made no mistakes that will affect what you are doing.
Kind of like building on ground where you can't check whether it actually is a swamp. In fact, it is illegal for you to check whether it is a swamp, and you have to build on that ground because "everybody else does it". And where the holy creator of the ground thought that investing 20% of the necessary work is good enough.
Friday, June 1, 2007
Charity for the Rich (a tangent)
Let's leave progress aside, for a moment, and look at a very strange development:
Year after year, developers all over the world donate their expensive time to rich corporations like Microsoft or Linden Labs for free... and for no added value to themselves or their products. Not only that, but the time and money also just get thrown away by the corporations they donate it to! Why? Let's see.
Let's take Microsoft as the first example.
Every time you design a web site, you can do it one of two ways: standard-compliant, or Microsoft. These two are mutually exclusive, since Microsoft decided to take the otherwise standard tags, CSS rules etc, and render them differently from everybody else. There are scores of websites dedicated to how to work around "misapplications of standards" (which are, in my opinions, bugs and not a separate class of problem.)
Every web designer who wants his website to be viewed both by IE users, and by everybody else, basically has to develop his web site twice, or at least spend a lot of time learning the incompatibilities of IE to other browsers, and IE7 to IE6 to IE5 and so on, and ways to make his web site work with every one of those more-or-less properly -- since all of those browsers have different sets of problems. Most people I know who stopped doing web design, have stopped for this exact reason.
Why does this problem exist? Because Microsoft considers it more important to fix some bugs then others (as can be read frequently on Chris Wilson's blog), completely disregarding the fact that fixing some bugs will either make IE-recognizing code fail, or the browser will be recognized as IE but will not render the web page as expected, resulting in the necessity to add yet another version of the same web page, to cater for yet another partially correct version of IE. (See also, IE8 announced. Opt in? Does this mean, I have to go back to all my pages and add new code that will cause IE8 to render it the same as Firefox already does it?)
To sum it up: because Microsoft doesn't want to invest money in standard compliance, every single web developer has to invest money out of his own pocket to fix Microsoft's problems.
WOW! This is a perfect example of capitalism: extracting surplus value from somebody who isn't even your employee!
Except... the amount of money wasted worldwide in this operation is -- even by a conservative estimate -- hundreds of times larger than the amount of money Microsoft would have to invest to fix the problem. (Just compare the number of website developers worldwide that have to cope with the problem to the amount of developers working on IE.)
And with this, we arrive at Linden Labs.
There has been a lot of attention to Second Life, the Linden Labs' 3D environment, lately. As I noted earlier on a different blog (I will re-post it here eventually), Second Life is neither unique, nor technologically more advanced than similar solutions (e.g. There.com). What makes them unique is that creating new content is really cheap: the environment has a (crappy) built-in object editor, and uploading new textures costs only L$10 -- about 3 cents. They also allow you to sell stuff, and earn L$, which can be easily converted into real (US) Dollars, at a price.
Many a developer starts, starry-eyed, to develop new content for the system, thinking of what great things you could potentially do in a 3D environment. Some of them do manage to create decent things (and some of them, even, to sell them), before they ultimately collide with the technological barriers of the Linden Scripting Language and Second Life physics. Which, to put it gently, suck ocean liners through cocktail straws. For example, until March 2007 you could not create animals that actually moved their legs, without writing a distributed swarm-like system of scripts -- one for every joint. And if you actually manage to write something that doesn't collapse under the weight of its own code, you would discover that the physics system has bugs that prevent the "animal" from working properly anyway.
But I digress.
The really interesting fact about Second Life is that most of the contentsucks is created by it's users, whereas most of the money is made by Linden Labs, since you pay them
In fact, now that they open-sourced the Second Life client, they don't even have to maintain their 3D client themselves, as hundreds of enthusiasts are fixing their code for them too -- donating their time to a company that is bathing in money. Money enough, in fact, so that they can just buy additional servers, and not worry about the fact that the server code is as inefficient as it is... But that is a subject of a different discussion.
And you know what? They waste most of the users' efforts, too.
Almost every Wednesday, the entire Second Life network goes down for maintenance. When it comes back, often enough, many objects that worked perfectly before, don't any more. Because, for example, a five-year-old bug that everybody had to work around, and which had been incorporated into every moving object as a feature, got "fixed". Which means, just as with every version of IE (which, luckily for us, doesn't come around quite that often), every programmer has to check every script after every update. Not many do, which means that a significant percentage of scripts, objects and weapons in Second Life are broken at any given time.
The interesting difference between Linden Labs and Microsoft is: Microsoft is just a wannabe monopolist of the Web, while Linden Labs has absolute control over Second Life. Linden Scripting Language is their own invention, used nowhere but in Second Life -- so if they choose to say "everybody uses this, we should not fix it", nobody would complain, because unlike the case of Microsoft and the web standards, it would be a fact, with "everybody" actually being 100% of Second Life developers who use the given function, since there is no alternative.
So, what do we learn from these examples?
If we donate our time and money to corporations that don't actually need it, they will not say "thank you" -- they will, in fact, not even think about it, respect it, or pay any attention to it.
So if you are a developer... just don't do it. If you want to donate your time and your knowledge to something, choose an Open Source project. At least in this case, the user community will profit, instead of it being a complete waste of your time.
Year after year, developers all over the world donate their expensive time to rich corporations like Microsoft or Linden Labs for free... and for no added value to themselves or their products. Not only that, but the time and money also just get thrown away by the corporations they donate it to! Why? Let's see.
Let's take Microsoft as the first example.
Every time you design a web site, you can do it one of two ways: standard-compliant, or Microsoft. These two are mutually exclusive, since Microsoft decided to take the otherwise standard tags, CSS rules etc, and render them differently from everybody else. There are scores of websites dedicated to how to work around "misapplications of standards" (which are, in my opinions, bugs and not a separate class of problem.)
Every web designer who wants his website to be viewed both by IE users, and by everybody else, basically has to develop his web site twice, or at least spend a lot of time learning the incompatibilities of IE to other browsers, and IE7 to IE6 to IE5 and so on, and ways to make his web site work with every one of those more-or-less properly -- since all of those browsers have different sets of problems. Most people I know who stopped doing web design, have stopped for this exact reason.
Why does this problem exist? Because Microsoft considers it more important to fix some bugs then others (as can be read frequently on Chris Wilson's blog), completely disregarding the fact that fixing some bugs will either make IE-recognizing code fail, or the browser will be recognized as IE but will not render the web page as expected, resulting in the necessity to add yet another version of the same web page, to cater for yet another partially correct version of IE. (See also, IE8 announced. Opt in? Does this mean, I have to go back to all my pages and add new code that will cause IE8 to render it the same as Firefox already does it?)
To sum it up: because Microsoft doesn't want to invest money in standard compliance, every single web developer has to invest money out of his own pocket to fix Microsoft's problems.
WOW! This is a perfect example of capitalism: extracting surplus value from somebody who isn't even your employee!
Except... the amount of money wasted worldwide in this operation is -- even by a conservative estimate -- hundreds of times larger than the amount of money Microsoft would have to invest to fix the problem. (Just compare the number of website developers worldwide that have to cope with the problem to the amount of developers working on IE.)
And with this, we arrive at Linden Labs.
There has been a lot of attention to Second Life, the Linden Labs' 3D environment, lately. As I noted earlier on a different blog (I will re-post it here eventually), Second Life is neither unique, nor technologically more advanced than similar solutions (e.g. There.com). What makes them unique is that creating new content is really cheap: the environment has a (crappy) built-in object editor, and uploading new textures costs only L$10 -- about 3 cents. They also allow you to sell stuff, and earn L$, which can be easily converted into real (US) Dollars, at a price.
Many a developer starts, starry-eyed, to develop new content for the system, thinking of what great things you could potentially do in a 3D environment. Some of them do manage to create decent things (and some of them, even, to sell them), before they ultimately collide with the technological barriers of the Linden Scripting Language and Second Life physics. Which, to put it gently, suck ocean liners through cocktail straws. For example, until March 2007 you could not create animals that actually moved their legs, without writing a distributed swarm-like system of scripts -- one for every joint. And if you actually manage to write something that doesn't collapse under the weight of its own code, you would discover that the physics system has bugs that prevent the "animal" from working properly anyway.
But I digress.
The really interesting fact about Second Life is that most of the content
- every time you upload anything
- every time you change dollars into L$
- every time you change L$ into dollars
- every month -- if you "own" a piece of virtual property
In fact, now that they open-sourced the Second Life client, they don't even have to maintain their 3D client themselves, as hundreds of enthusiasts are fixing their code for them too -- donating their time to a company that is bathing in money. Money enough, in fact, so that they can just buy additional servers, and not worry about the fact that the server code is as inefficient as it is... But that is a subject of a different discussion.
And you know what? They waste most of the users' efforts, too.
Almost every Wednesday, the entire Second Life network goes down for maintenance. When it comes back, often enough, many objects that worked perfectly before, don't any more. Because, for example, a five-year-old bug that everybody had to work around, and which had been incorporated into every moving object as a feature, got "fixed". Which means, just as with every version of IE (which, luckily for us, doesn't come around quite that often), every programmer has to check every script after every update. Not many do, which means that a significant percentage of scripts, objects and weapons in Second Life are broken at any given time.
The interesting difference between Linden Labs and Microsoft is: Microsoft is just a wannabe monopolist of the Web, while Linden Labs has absolute control over Second Life. Linden Scripting Language is their own invention, used nowhere but in Second Life -- so if they choose to say "everybody uses this, we should not fix it", nobody would complain, because unlike the case of Microsoft and the web standards, it would be a fact, with "everybody" actually being 100% of Second Life developers who use the given function, since there is no alternative.
So, what do we learn from these examples?
If we donate our time and money to corporations that don't actually need it, they will not say "thank you" -- they will, in fact, not even think about it, respect it, or pay any attention to it.
So if you are a developer... just don't do it. If you want to donate your time and your knowledge to something, choose an Open Source project. At least in this case, the user community will profit, instead of it being a complete waste of your time.
Progress v6: is the age of standards the worst enemy of Progress?
[This is my sixth article on Progress. I'm sorry for the long period of silence on that matter, the real life had caught up with me, but there is also good news: this is not, as planned, the last article on progress. There is at least one more, or more likely, two more, to come.]
In the previous five articles I made the impression, that contrary to the public opinion, to achieve actual progress, older is better. And in the cases I mentioned, it is. But let's look at an extreme example of this, the by now fairly well known story that "space shuttle engine's width is two horse asses plus X".
While the latest conclusion is, that, indeed, this is an urban legend, and the space shuttle might not have any relation to a horse's ass whatsoever, the basic story (bar the newer, Usenet-based addition with the space shuttle), that the width of the railroad track is based on the dimensions of two horse rears, same as the chariot width in the old Rome is affirmed in the same article:
is both somewhat true,... and, to a degree, a circular argument: "The war was won partly because of the railroad gauge, but had the war taken a different course, the railroad gauge would have been different." (If the outcome of the war wouldn't have depended on the railroad gauge, that is?)
The second, and most important, conclusion is, in a collaborative environment, it is better to use well-established standards then not to use them: having a standard-sized railroad might have helped the South to win the war, by allowing the trains to pass through an unified railroad system instead of having to unload and re-load trains (or change the gauge on the wagons, as they do it when trains transit from e.g. Russia into western Europe and vice-versa).
And in modern times, there is even more to say for keeping of the standard: even though the width of the railroad track might not be entirely optimal for modern trains, there is an enormous amount of existing equipment based on the standard, which would ALL have to be changed if somebody decided to switch standards.
Or in other words, there is no reason not to use a standard just because it is 2000 years old, but there is a lot of reason to re-use existing equipment. And it doesn't preclude us in the least from making progress, (for example, in this particular case, from developing high-speed trains like ICE3 and TGV)
Which, incidentally, is what I have been saying for the last five articles. So no, the age of standards doesn't impede progress to any significant degree, if the standards make sense. This is an important distinction. The history of science would be much more straightforward if it wasn't. How so?... Come back next week(or next month?), and see for yourself, in... Progress wars! ;-)
In the previous five articles I made the impression, that contrary to the public opinion, to achieve actual progress, older is better. And in the cases I mentioned, it is. But let's look at an extreme example of this, the by now fairly well known story that "space shuttle engine's width is two horse asses plus X".
While the latest conclusion is, that, indeed, this is an urban legend, and the space shuttle might not have any relation to a horse's ass whatsoever, the basic story (bar the newer, Usenet-based addition with the space shuttle), that the width of the railroad track is based on the dimensions of two horse rears, same as the chariot width in the old Rome is affirmed in the same article:
[...]the dimension common to both was that of a cart axle pulled by two horses in harness (about 1.4m orThe same article also says:4ft 8in ). This determined both the Roman gauge and Stephenson's, which derived from the horsedrawn wagon ways of South Northumberland and County Durham coalfields.[...]
[from: Crow, James. Housesteads. London: B.T. Batsford, 1995. ISBN 0-7134-6085-7 (pp. 33-34).]
At the time of the Civil War, even though nearly all of the Confederacy's railroad equipment had come from the North or from Britain (of the 470 locomotives built in the U.S. in 1860, for example, only 19 were manufactured in the South), 113 different railroad companies in the Confederacy operated on three different gauges of track. This lack of standardization was, as historian James McPherson points out, one of the many reasons the Union was able to finally vanquish the Confederacy militarily:So what does this tell us? First of all, that the conclusion thatThe Confederate government was never able to coax the fragmented, run-down, multi-gauged network of southern railroads into the same degree of efficiency exhibited by northern roads. This contrast illustrated another dimension of Union logistical superiority that helped the North eventually to prevail.
[from: McPherson, James. Battle Cry of Freedom. New York: Oxford Univ. Press, 1988. ISBN 0-19-503863-0 (pp. 318-319, 514-515)]
In other words, there was nothing inevitable about a railroad gauge supposedly traceable to the size of wheel ruts in Imperial Rome. Had the Civil War taken a different course, the eventual standard railroad gauge used throughout North America might well have been different than the current one.
is both somewhat true,... and, to a degree, a circular argument: "The war was won partly because of the railroad gauge, but had the war taken a different course, the railroad gauge would have been different." (If the outcome of the war wouldn't have depended on the railroad gauge, that is?)
The second, and most important, conclusion is, in a collaborative environment, it is better to use well-established standards then not to use them: having a standard-sized railroad might have helped the South to win the war, by allowing the trains to pass through an unified railroad system instead of having to unload and re-load trains (or change the gauge on the wagons, as they do it when trains transit from e.g. Russia into western Europe and vice-versa).
And in modern times, there is even more to say for keeping of the standard: even though the width of the railroad track might not be entirely optimal for modern trains, there is an enormous amount of existing equipment based on the standard, which would ALL have to be changed if somebody decided to switch standards.
Or in other words, there is no reason not to use a standard just because it is 2000 years old, but there is a lot of reason to re-use existing equipment. And it doesn't preclude us in the least from making progress, (for example, in this particular case, from developing high-speed trains like ICE3 and TGV)
Which, incidentally, is what I have been saying for the last five articles. So no, the age of standards doesn't impede progress to any significant degree, if the standards make sense. This is an important distinction. The history of science would be much more straightforward if it wasn't. How so?... Come back next week(or next month?), and see for yourself, in... Progress wars! ;-)
Sunday, May 13, 2007
Progress v5: Is greed the worst enemy of progress?
[This is my fifth article on progress. Believe it or not, more is coming]
In the previous article we've seen that marketing is not a friend of progress, because it binds existing know-how into doing useless things. But why do companies see fit to create hype? Why on earth would two big corporations go to the length to create programming languages and to create a hype around them? And why would entrepreneurs generate Buzzwords like WEB2.0 and sell their business plans based on those?
Let's take those examples one by one.
The companies' explanation for the programming language hype was:
"because it is cross-platform" and "because it is simple and powerful".
Simple? How long does it take a newbie to get the signature of "public static void main(String[] args)" right? And to remember to wrap it in a "public class Foo"? (remember, there was no eclipse or netbeans when "java" started, no auto-completion etc.) A Foo that is also in it's own, properly named file? And that he has to rename the file to Foo.java (from foo.java or FOO.JAVA) when he copies the file to any real file system?
Now why didn't they, for example, take a sub-set of C++ and modified it to produce byte code similar to java's? It's not that hard to change the assembler part of an existing machinery. Or a language similar to Pascal or Delphi, if they wanted a "stricter" language? Why invent a language with a longer (and therefore slower to type ==> more typo-prone) syntax that had, at the beginning, any number of shortcomings to compensate for the benefit of the garbage collector? (Oh, by the way, pretty much all scripting languages where you can dynamically create objects and reference them have one, even Visual Basic.)
I'd say, it suspiciously looks like the real reasons were
- because they wanted to OWN a programming language (tm).
- because they didn't want new software that would compile with existing compilers out there, but wanted to bind people to their platform.
- because if you own a programming language, you can sell all kinds of things associated with it:
- lessons
- books
- software services
- additional software libraries (..."enterprise editions"...)
- Also, at the beginning you are the only one who can. Since you invented it, and you own it, and you don't publish the specs until way later when other people start to write books and libraries for your language.
- At which point you simply create a new version that has new features that are not backwards-compatible to the old one, and start selling new books and libraries for that one.
- rinse, repeat, ad nauseum.
And how do you bait people into it?
- promise "cross-platform" ("compile once, run anywhere"), since this is a known problem in the software industry.
- promise "less error-prone" and "faster software development" through "garbage collection" and "type safety".
(The solution of using a sub-set of C++ where you make certain operators illegal and that compiles into a byte code would, by the way, do the very same thing, but allow you to compile the stuff with existing compilers, and allow existing C++ programmers with >10-15 years of experience to program on the new platform with no adjustment time. And this would be bad... how?).
Summary: the motivation is to create a new, previously non-existing market. To earn money. In other words, greed.
And since Microsoft EXCELs at greed, they simply had to follow that trail with .NET. Promising basically the same things.
And of course, the motivation to put IT-Buzzwords (WEB2.0, AJAX, XML, ...) on a business plan is exactly the same: attract investors => get money. And of course the entrepreneur would do that. Since the investor wouldn't budge unless he SEES a buzzword! Or how else should he, who has no idea of the trade, recognize what's worth investing into?
Take AJAX, for example. It looks very much like the word has been invented/hyped solely for that reason -- since people have been using the actual technologies behind it for years (a little google search will help), and also, in many configurations used today technically it's not really AJAX because it transfers the data as YAML or javascript/JSON -- because with many types of data XML garbage-to-data ratio is a little high. Like, 2:1 or worse. Even java2 object serialization has a compacter format and is faster to parse... But that's a different topic.)
So what does all of that tells us? Similar to the points I've discussed in PrOgReSs V3:
- If somebody invents a new toolbox and convinces people that "his is better" while it is actually not, or
- if people are forced to re-start their projects using buzzword technologies instead of working technologies because otherwise they don't get funded,
it takes people with know-how working on exiting projects, and binds them learning the new stuff that doesn't let them accomplish whatever they were working on any faster. Which means, now they have to add the learning curve of the new stuff to the time their projects need to get done -- with no additional benefit.
And greed (or some would say, capitalism) is responsible for both of the phenomena.
So is greed the worst enemy of progress?
Well, that could very well be. But there is a little more to that story. It has to do with human life span, experience, time, and of course, progress. Tune in for the next episode of the progress wars... ;-) probably next week.
In the previous article we've seen that marketing is not a friend of progress, because it binds existing know-how into doing useless things. But why do companies see fit to create hype? Why on earth would two big corporations go to the length to create programming languages and to create a hype around them? And why would entrepreneurs generate Buzzwords like WEB2.0 and sell their business plans based on those?
Let's take those examples one by one.
The companies' explanation for the programming language hype was:
"because it is cross-platform" and "because it is simple and powerful".
Simple? How long does it take a newbie to get the signature of "public static void main(String[] args)" right? And to remember to wrap it in a "public class Foo"? (remember, there was no eclipse or netbeans when "java" started, no auto-completion etc.) A Foo that is also in it's own, properly named file? And that he has to rename the file to Foo.java (from foo.java or FOO.JAVA) when he copies the file to any real file system?
Now why didn't they, for example, take a sub-set of C++ and modified it to produce byte code similar to java's? It's not that hard to change the assembler part of an existing machinery. Or a language similar to Pascal or Delphi, if they wanted a "stricter" language? Why invent a language with a longer (and therefore slower to type ==> more typo-prone) syntax that had, at the beginning, any number of shortcomings to compensate for the benefit of the garbage collector? (Oh, by the way, pretty much all scripting languages where you can dynamically create objects and reference them have one, even Visual Basic.)
I'd say, it suspiciously looks like the real reasons were
- because they wanted to OWN a programming language (tm).
- because they didn't want new software that would compile with existing compilers out there, but wanted to bind people to their platform.
- because if you own a programming language, you can sell all kinds of things associated with it:
- lessons
- books
- software services
- additional software libraries (..."enterprise editions"...)
- Also, at the beginning you are the only one who can. Since you invented it, and you own it, and you don't publish the specs until way later when other people start to write books and libraries for your language.
- At which point you simply create a new version that has new features that are not backwards-compatible to the old one, and start selling new books and libraries for that one.
- rinse, repeat, ad nauseum.
And how do you bait people into it?
- promise "cross-platform" ("compile once, run anywhere"), since this is a known problem in the software industry.
- promise "less error-prone" and "faster software development" through "garbage collection" and "type safety".
(The solution of using a sub-set of C++ where you make certain operators illegal and that compiles into a byte code would, by the way, do the very same thing, but allow you to compile the stuff with existing compilers, and allow existing C++ programmers with >10-15 years of experience to program on the new platform with no adjustment time. And this would be bad... how?).
Summary: the motivation is to create a new, previously non-existing market. To earn money. In other words, greed.
And since Microsoft EXCELs at greed, they simply had to follow that trail with .NET. Promising basically the same things.
And of course, the motivation to put IT-Buzzwords (WEB2.0, AJAX, XML, ...) on a business plan is exactly the same: attract investors => get money. And of course the entrepreneur would do that. Since the investor wouldn't budge unless he SEES a buzzword! Or how else should he, who has no idea of the trade, recognize what's worth investing into?
Take AJAX, for example. It looks very much like the word has been invented/hyped solely for that reason -- since people have been using the actual technologies behind it for years (a little google search will help), and also, in many configurations used today technically it's not really AJAX because it transfers the data as YAML or javascript/JSON -- because with many types of data XML garbage-to-data ratio is a little high. Like, 2:1 or worse. Even java2 object serialization has a compacter format and is faster to parse... But that's a different topic.)
So what does all of that tells us? Similar to the points I've discussed in PrOgReSs V3:
- If somebody invents a new toolbox and convinces people that "his is better" while it is actually not, or
- if people are forced to re-start their projects using buzzword technologies instead of working technologies because otherwise they don't get funded,
it takes people with know-how working on exiting projects, and binds them learning the new stuff that doesn't let them accomplish whatever they were working on any faster. Which means, now they have to add the learning curve of the new stuff to the time their projects need to get done -- with no additional benefit.
And greed (or some would say, capitalism) is responsible for both of the phenomena.
So is greed the worst enemy of progress?
Well, that could very well be. But there is a little more to that story. It has to do with human life span, experience, time, and of course, progress. Tune in for the next episode of the progress wars... ;-) probably next week.
Saturday, April 28, 2007
PROGRESS V4.0: is marketing the worst enemy of Progress?
[This is my forth article on progress -- tune back in for more! The first article is here.]
Fashions come and go. It seems so natural, there are dress fashions, health fashions, diet fashions, so why not software fashions too?
Well, actually, we have seen in the last article why not. A better question is, are fashions "natural", and how do they start?
Well, I can't say how a dress fashion starts. None of my outfits are concerned with fashion in the least, they are concerned with placing things that I need to carry with me in places that don't annoy me while walking or working.
I can tell you, though, how fashion in software starts. It starts with a hype.
Now, of course, the hype doesn't come from no-where.
Remember Java? It was the hype of the time when I was just starting to discover the internet. It was started not by a community of developers, or researchers at a university, or anything like that. It was started by SUN, an enormous hardware, software and service company. Just as, about ten years later, Microsoft tried to jump on the same bandwagon with .NET. Both of those "hypes" were generated and pushed by the Sales/Marketing divisions of those companies.
Another fashion is XML. This one is a very different kind of fashion, since it, from all I can see, started out from W3C creating XML to use as a standardized replacement for HTML. It was a free text markup language backwards-compatible with HTML and extensible, too. It is very good in that role. However, I can't quite find out who's idea it was to use it for pure data. It wasn't obvious, since better formats exist since 1985 (if libraries for ASN.1 would be as widely available as those for XML, it's perceived complexity would not be an issue). Nor is it difficult to design a better format for that purpose, text-based or binary.
But one of the most frequent sentences said at the beginning of the XML hype was "if all applications can XML, they can all exchange data with each other!". Which, as you probably know by now, is neither so, nor does it make sense, since there is no way in XML itself to assign any intrinsic "meaning" to a tag, an application doesn't know whether a tag "p" stands for paragraph, person, parity or pound, neither is there a way to declare meaning like this in the underlying schema documents (though this might eventually evolve, but so it could with any other hierarchical(-lish) extensible language).
Fashions come and go. It seems so natural, there are dress fashions, health fashions, diet fashions, so why not software fashions too?
Well, actually, we have seen in the last article why not. A better question is, are fashions "natural", and how do they start?
Well, I can't say how a dress fashion starts. None of my outfits are concerned with fashion in the least, they are concerned with placing things that I need to carry with me in places that don't annoy me while walking or working.
I can tell you, though, how fashion in software starts. It starts with a hype.
Now, of course, the hype doesn't come from no-where.
Remember Java? It was the hype of the time when I was just starting to discover the internet. It was started not by a community of developers, or researchers at a university, or anything like that. It was started by SUN, an enormous hardware, software and service company. Just as, about ten years later, Microsoft tried to jump on the same bandwagon with .NET. Both of those "hypes" were generated and pushed by the Sales/Marketing divisions of those companies.
Another fashion is XML. This one is a very different kind of fashion, since it, from all I can see, started out from W3C creating XML to use as a standardized replacement for HTML. It was a free text markup language backwards-compatible with HTML and extensible, too. It is very good in that role. However, I can't quite find out who's idea it was to use it for pure data. It wasn't obvious, since better formats exist since 1985 (if libraries for ASN.1 would be as widely available as those for XML, it's perceived complexity would not be an issue). Nor is it difficult to design a better format for that purpose, text-based or binary.
But one of the most frequent sentences said at the beginning of the XML hype was "if all applications can XML, they can all exchange data with each other!". Which, as you probably know by now, is neither so, nor does it make sense, since there is no way in XML itself to assign any intrinsic "meaning" to a tag, an application doesn't know whether a tag "p" stands for paragraph, person, parity or pound, neither is there a way to declare meaning like this in the underlying schema documents (though this might eventually evolve, but so it could with any other hierarchical(-lish) extensible language).
The sentence, though, was marketing. Not of the big companies for the consumer, mind you, back then, he was unlikely to encounter XML anywhere but as XHTML on a web page. But: enough people who invest into IT don't actually understand it, as you could nicely see during the bursting of the .com bubble. And they bought shares in new and promising buzzword startups, thinking, "Yey, now we can invest into companies making programs that can understand everything!". Some of them actually survived and made money. But so do the top levels in a pyramid scheme (which, as you probably know, generates no additional value
whatsoever)
In all three cases there would have been prior, superior alternatives with existing infrastructure to invest into, and extend. You know, progress. And the only reason it didn't happen, was marketing.
Which lets us conclude: marketing is not a friend of progress.
But the marketing division doesn't just go out there and start promoting things, either. Neither is it a mere coincidence that marketing buzzwords are parts of startups' business plans. What is the reason for marketing? Is there maybe an even bigger enemy of progress lurking in the background? The answer -- in the next article!
Sunday, April 22, 2007
PrOgReSs v3: Is fashion the worst enemy of progress?
[This is my third article on progress. The first article is here. More is coming, including the promised "sales department" part.]
What has fashion to do with computers? Well, that's easy. When my grandfather was programmer ( ; ), COBOL and LISP were "in". The day before yesterday, C/C++ was hip. Yesterday, Java was cool. Today, Dot-HET is "dah coolest evah", and "java suxxorz". Tomorrow, it will be something else.
"But wait", you'll say, "this is progress!"
Erhm... is that a fact? Entire software development suites exist written purely in LISP. LISP has a byte-compiler, just like Java, and would be just as cross-platform (not to mention that it is much easier to parse for computers, and looks not any worse then XML does, except for less text. And XML is "in" now, isn't it?) In C/C++ you can do everything you can do in Java, with less text. Dot-nyet's C# is a weird mix between Pascal (!), C++ and Java with some "novel" concepts most of which you easily can replicate using C++. The idea to have a set of standard libraries for "everything" on a platform is also not that new. The C/C++ libraries are somewhat limited, I agree, but I remember standard GUI libraries being used on AMIGA (integrated in it's ROM), in 1992, and you could access them from the AMIGA's assembler really easily. (In fact, the source code of an AMIGA program opening a pop-up box in assembler is about as long or even shorter then the same program written in Java -- so much for "high level"). I'm sure, someone out there remembers an older example.
If you sit down and compare the features, you will find out that the capabilities of most high-level and/or object-enabled languages, old and new, are very similar, not to say, almost the same. Which is why many people still use LISP, and C/C++, and, well, COBOL. (The latter is probably being phased out of active use, mainly because no-one can program it any more.)
The same is true not just for programming languages, but also for other technologies. Just look at how popular technology buzzwords change overtime (I wanted to give a link to the google keyword popularity comparison here, that I've seen in December 2006, but I can't seem to find it any more in April 2007. I guess that was also a thing of fashion...).
For those of you who have a long-term memory though, just remember the technology buzzwords from ten, five and one year ago. How many of them are still there?
"But what's so bad about this?" you might ask, "isn't fashion what's keeping the industry alive? They can sell new things!"
That might well be. But we are looking at progress now. As in, what brings our knowledge and our technology forward. And "new things" that are created this way don't:
Remember my first post? The same problem as with the perfectionism applies to fashion: software is built on other software. Just like in science, where theories are built on other theories.
If people don't buy or finance projects that are based on the most current, the most hip library, it doesn't really matter how many projects you finish: you will never bring a project past a certain point. It is like trying to build a house where every time you want to build a second floor, somebody says "but we have a better material for the first floor now, let's tear it down and build it out of that": the second floor will never be built. You are just doing the same thing over and over again. That's not progress, that's marching in one spot.
But why do people keep doing that? Why do we switch programming languages, libraries, technologies? Why does this fashion-thing exist in the software world -- is it a matter of tastes, or is there something else in play?
The answer, as always, is in the next post. Incidentally, it will also be a continuation of the last post.
What has fashion to do with computers? Well, that's easy. When my grandfather was programmer ( ; ), COBOL and LISP were "in". The day before yesterday, C/C++ was hip. Yesterday, Java was cool. Today, Dot-HET is "dah coolest evah", and "java suxxorz". Tomorrow, it will be something else.
"But wait", you'll say, "this is progress!"
Erhm... is that a fact? Entire software development suites exist written purely in LISP. LISP has a byte-compiler, just like Java, and would be just as cross-platform (not to mention that it is much easier to parse for computers, and looks not any worse then XML does, except for less text. And XML is "in" now, isn't it?) In C/C++ you can do everything you can do in Java, with less text. Dot-nyet's C# is a weird mix between Pascal (!), C++ and Java with some "novel" concepts most of which you easily can replicate using C++. The idea to have a set of standard libraries for "everything" on a platform is also not that new. The C/C++ libraries are somewhat limited, I agree, but I remember standard GUI libraries being used on AMIGA (integrated in it's ROM), in 1992, and you could access them from the AMIGA's assembler really easily. (In fact, the source code of an AMIGA program opening a pop-up box in assembler is about as long or even shorter then the same program written in Java -- so much for "high level"). I'm sure, someone out there remembers an older example.
If you sit down and compare the features, you will find out that the capabilities of most high-level and/or object-enabled languages, old and new, are very similar, not to say, almost the same. Which is why many people still use LISP, and C/C++, and, well, COBOL. (The latter is probably being phased out of active use, mainly because no-one can program it any more.)
The same is true not just for programming languages, but also for other technologies. Just look at how popular technology buzzwords change overtime (I wanted to give a link to the google keyword popularity comparison here, that I've seen in December 2006, but I can't seem to find it any more in April 2007. I guess that was also a thing of fashion...).
For those of you who have a long-term memory though, just remember the technology buzzwords from ten, five and one year ago. How many of them are still there?
"But what's so bad about this?" you might ask, "isn't fashion what's keeping the industry alive? They can sell new things!"
That might well be. But we are looking at progress now. As in, what brings our knowledge and our technology forward. And "new things" that are created this way don't:
Remember my first post? The same problem as with the perfectionism applies to fashion: software is built on other software. Just like in science, where theories are built on other theories.
If people don't buy or finance projects that are based on the most current, the most hip library, it doesn't really matter how many projects you finish: you will never bring a project past a certain point. It is like trying to build a house where every time you want to build a second floor, somebody says "but we have a better material for the first floor now, let's tear it down and build it out of that": the second floor will never be built. You are just doing the same thing over and over again. That's not progress, that's marching in one spot.
But why do people keep doing that? Why do we switch programming languages, libraries, technologies? Why does this fashion-thing exist in the software world -- is it a matter of tastes, or is there something else in play?
The answer, as always, is in the next post. Incidentally, it will also be a continuation of the last post.
Sunday, April 15, 2007
Progress v2: Is the Pareto Principle the worst enemy of Progress?
[This is my second article on Progress. The first article is here. Keep tuned in for more. It is coming. Really!]
As we've seen in my last post, perfectionism doesn't do well in the face of the rapid progress of the current software-internet-turbo-world. So how does the industry ever finish any projects?
The short answer is, by using an interpretation of the 80/20 rule, also known as the Pareto Principle.
The used interpretation differs from one company to the other. Unfortunately, in the software industry (spell m-i-c-... etc) the interpretation in question is, "You can achieve 80% of the intended result by investing 20% of effort".
The corollary of that interpretation is, to achieve the remaining 20% of the intended result, you need to invest the other 80% of effort. And business don't play that.
Which often enough results in released products ~80-90% ready, because it simply doesn't pay off to invest more effort to make the product "more ready".
Since later software almost always relies on previously created software-libraries, or tries to stay compatible (often even bug-compatible) to already existing software, the application of the 80/20 rule results in "progress" being made at the cost of quality, and also, the bugs of every product built on top of an existing buggy product compound, the end product becoming progressively worse. (The same is also true for other forms of modular technology, e.g. computer hardware.)
Also, unfortunately, the final 80% of the effort in the "traditional" software development methodology (as opposed to the agile software development) is debugging, which also explains the quality of some software products out there.
With this in mind, the Pareto principle can be easily converted into a weaker form of Sturgeon's Law - at least 80% of everything we produce in the name of Progress is crap.
But then, if nothing is ever perfect, it is easier to sell something new by claiming that it is better. And that's why, next time, we'll see how the sales department deals with the notion of progress.
As we've seen in my last post, perfectionism doesn't do well in the face of the rapid progress of the current software-internet-turbo-world. So how does the industry ever finish any projects?
The short answer is, by using an interpretation of the 80/20 rule, also known as the Pareto Principle.
The used interpretation differs from one company to the other. Unfortunately, in the software industry (spell m-i-c-... etc) the interpretation in question is, "You can achieve 80% of the intended result by investing 20% of effort".
The corollary of that interpretation is, to achieve the remaining 20% of the intended result, you need to invest the other 80% of effort. And business don't play that.
Which often enough results in released products ~80-90% ready, because it simply doesn't pay off to invest more effort to make the product "more ready".
Since later software almost always relies on previously created software-libraries, or tries to stay compatible (often even bug-compatible) to already existing software, the application of the 80/20 rule results in "progress" being made at the cost of quality, and also, the bugs of every product built on top of an existing buggy product compound, the end product becoming progressively worse. (The same is also true for other forms of modular technology, e.g. computer hardware.)
Also, unfortunately, the final 80% of the effort in the "traditional" software development methodology (as opposed to the agile software development) is debugging, which also explains the quality of some software products out there.
With this in mind, the Pareto principle can be easily converted into a weaker form of Sturgeon's Law - at least 80% of everything we produce in the name of Progress is crap.
But then, if nothing is ever perfect, it is easier to sell something new by claiming that it is better. And that's why, next time, we'll see how the sales department deals with the notion of progress.
Saturday, April 14, 2007
Progress v1: Is Perfectionism the worst enemy of Progress?
[This is the first entry in a series that deals with the notion of Progress. There will be more. I promise.]
Most of us grew up with the notion, that the world is moving forward. Developing. Progressing.
Progress is good. New developments are good. Good for business, good for our living standard.
Software, too, is progressing. Ever new development models, languages and components are invented. Software is built on those. Software is built out of that software. And then rebuilt, using newer components, because newer is better. And then rebuilt again, using still newer components. And then...
Oh wait. Is that still progress we are talking about?
I don't know about other software developers, but I have, from time to time, met the point, where I have built a large and complex piece of software with the resources and tools I had available at the point, and it took me so long to develop that by the time I was done, it was technically obsolete because now there were newer tools and resources I could have used.
Now, the piece of software is done. Theoretically, I could sell it. Or, because I am a perfectionist, I could re-build it using the newer technologies. But by the time I'm done rebuilding it, there will be even newer tools and resources... Should I sell it then, or should I re-build it using those?
Or rather...
- am I ever going to be done with it and sell it?
And a corollary:
- does perfect and up-to-date software really exist, and who makes it?
Cheers,
Your Fly
And next time we are going to look at what the industry does with Progress. Because, well, industry isn't perfect ;-)
Most of us grew up with the notion, that the world is moving forward. Developing. Progressing.
Progress is good. New developments are good. Good for business, good for our living standard.
Software, too, is progressing. Ever new development models, languages and components are invented. Software is built on those. Software is built out of that software. And then rebuilt, using newer components, because newer is better. And then rebuilt again, using still newer components. And then...
Oh wait. Is that still progress we are talking about?
I don't know about other software developers, but I have, from time to time, met the point, where I have built a large and complex piece of software with the resources and tools I had available at the point, and it took me so long to develop that by the time I was done, it was technically obsolete because now there were newer tools and resources I could have used.
Now, the piece of software is done. Theoretically, I could sell it. Or, because I am a perfectionist, I could re-build it using the newer technologies. But by the time I'm done rebuilding it, there will be even newer tools and resources... Should I sell it then, or should I re-build it using those?
Or rather...
- am I ever going to be done with it and sell it?
And a corollary:
- does perfect and up-to-date software really exist, and who makes it?
Cheers,
Your Fly
And next time we are going to look at what the industry does with Progress. Because, well, industry isn't perfect ;-)
Wednesday, April 4, 2007
Adobe: a license to spam?
For all of you who expect a news article, or an abstract, here is what this article is about:
I always thought, spam should be illegal. I mean the electronic variety (though I wouldn't mind the "IMP" (Inedible Meat-like Product) to go the same way).
In fact, in some countries, like Germany, where I live, it is illegal (since 2004), and every US-Bill that I know of, that the spammers usually quote in a fashion similar to "this spam message is legal according to ..." hasn't actually passed into law. (And, can anybody tell me what happened to this US Bill?)
I always thought, no self-respecting large company manufacturing good software will go out there and spam.
I also always thought, a legit company doesn't need to spam, because all spam does to a company with a reputation is to damage it.
Today, though, I've got an email with the title, "Today, everything will change".
And suddenly, it did.
That particular mail contained clear indications of being spam -- including but not limited to
That email, though, was in English, and it was from "Adobe Systems Inc.".
At first I thought, it was a phishing scam. But no, all the www links point to http://direct.adobe.com/r?bmZmdWJ5cmZAbnFib3IucGJ6
(the code is changed so you don't accidentally register me)
Notice the "direct", for "direct marketing" as in "unsolicited email", adobe.com as in THE Adobe Systems Inc., and r, as in "register"?
I abstain from posting the full text, since that would be just more marketing for Adobe anyway. I should just say, that the email was about their new, horrendously expensive piece of software with the proposition:
Creative license
Take as much as you want.
They say it as "Complete creative freedom to work in any medium". After taking a look at the amount of products in the bundle, and recalling all the acquisitions by Adobe in the last years, it suddenly became clear to me: Adobe isn't just planning to monopolize the entire (commercial) graphics and video industry, it already did.
The "freedom to work in any medium" is just very carefully wrapped new-speak for "now all the software you'll ever need for web design, video or content creation, you'll either have to buy from us in a bundle that costs more then you earn in a month, of which you only will ever want one piece anyway, or write yourself".
After having seen similar "campaigns" from Microsoft and Apple before, I think I can safely paraphrase the above slogan as
Creating monopolies
We spam as much as we want.
Well, there is also good news for the graphics artists out there:
You can get Gimp for free, even on the Mac.
You see, Adobe forgot a teeny-tiny thing. They don't like open source, they don't endorse open source, and they close their eyes in the hopes that if they ignore it long enough it will go away. How 'bout we go away instead. From Adobe. Somewhere more pleasant.
For example, instead of going to the Adobe's "all young artists are belong to us" conference, why not attending Libre Graphics Meeting (http://www.libregraphicsmeeting.org/) instead, and learning of the newest and best in free graphics applications.
Also, Knoppix live DVDs contain many of the free graphics tools in one package. You don't even need to install them. Just download the disk image, burn the DVD (or buy it from a store near you, for example from on-disk for $5.99,* pop it into any computer that can read it, and go. The boot process is lengthy, but it will normally not ask you any technical questions, detect all your hardware automatically, and it doesn't install anything on your hard disk, allowing you to just play with the software at will. If there's nothing you like on the disk, just throw the DVD in the garbage (or erase the rewriteable) and never think about it again. It had cost you $6.
Unlike buying into a medium-size cattle farm called CS3, where you will have to pay for an upgrade every time they build a shinier fence, and also can't give it back once it's open. Which does sound suspiciously like a can of spam. Except, that, too, can be had at a much lower price.
Which reminds me: I know that every wannabe "direct marketing" company out there and many short-sighted small IT corporations that benefited from the original increase in public awareness will try to convince you that I'm wrong. A couple of studies though (for example "The effect of direct advertising to the dearly departed" ) show that spam is indeed not all roses. Most of the IT recognizes spam as a problem. 80% of all the email traffic is spam. And yes, we do pay for it. Even if you don't pay per time or per bulk any more, it is still included in the cost of your "flat rate" and prevents your provider from offering you a better price.
And also... When was the last time you heard somebody say that he was happy to receive a spam mail?
So what is the morale of this little story? Things have changed. Adobe just commited something that in parts of the world constitutes a crime, and waved "all your base..." in our faces. I just lost my last bit of respect for a company that at some point did manufacture quality software, after wasting half a day bitching about it, and added it to my spam filter. And you, my dear reader, might discover a bunch of powerful, new and free tools. Benefit for Adobe so far? Zero.
Case closed.
* - If you order the Knoppix-DVD, watch the version -- the newer, the better / the latter versions of the graphics software you'll usually get. It should be minimum Version 5.1.1 (as of the 4. of April, 2007).
- If you download the disk image, look that it fits to your architecture.(32 or 64 bit, etc).
- If you have trouble with Knoppix, try Ubuntu.
- If you already use Debian, or another linux distribution you can install many of the free tools using your package manager, e.g. aptitude on Debian. Just look through the "graphics" package :)
PS: Useful information about spam (the electronic variety) and how to deal with it, can be found here: www.stopspamhere.ca
- Adobe has turned to spamming in an attempt to advertise their newest product.
- It is something that many monopolists do, and indeed, Adobe is now a monopoly in the commercial segment of the field.
- spamming is illegal in many parts of the world, and rightly so. It is also a really bad idea.
- It is an especially bad idea, if there are free alternatives to your really expensive product.
- And there are. And I will show you where.
I always thought, spam should be illegal. I mean the electronic variety (though I wouldn't mind the "IMP" (Inedible Meat-like Product) to go the same way).
In fact, in some countries, like Germany, where I live, it is illegal (since 2004), and every US-Bill that I know of, that the spammers usually quote in a fashion similar to "this spam message is legal according to ..." hasn't actually passed into law. (And, can anybody tell me what happened to this US Bill?)
I always thought, no self-respecting large company manufacturing good software will go out there and spam.
I also always thought, a legit company doesn't need to spam, because all spam does to a company with a reputation is to damage it.
Today, though, I've got an email with the title, "Today, everything will change".
And suddenly, it did.
That particular mail contained clear indications of being spam -- including but not limited to
- web links with the encrypted ID of my email address
- the lack of a personal address or even my first or last name anywhere in the mail,
- the form,
- and the notorious "If you'd prefer not to receive e-mail like this from us in the future, please click here" text so well known from opt-out mailings -- which are illegal in Germany, and which are also known to mark your e-mail address as a better target for spam if you click on them, because now you've proven that it is a valid e-mail address.
That email, though, was in English, and it was from "Adobe Systems Inc.".
At first I thought, it was a phishing scam. But no, all the www links point to http://direct.adobe.com/r?bmZmdWJ5cmZAbnFib3IucGJ6
(the code is changed so you don't accidentally register me)
Notice the "direct", for "direct marketing" as in "unsolicited email", adobe.com as in THE Adobe Systems Inc., and r, as in "register"?
I abstain from posting the full text, since that would be just more marketing for Adobe anyway. I should just say, that the email was about their new, horrendously expensive piece of software with the proposition:
Creative license
Take as much as you want.
They say it as "Complete creative freedom to work in any medium". After taking a look at the amount of products in the bundle, and recalling all the acquisitions by Adobe in the last years, it suddenly became clear to me: Adobe isn't just planning to monopolize the entire (commercial) graphics and video industry, it already did.
The "freedom to work in any medium" is just very carefully wrapped new-speak for "now all the software you'll ever need for web design, video or content creation, you'll either have to buy from us in a bundle that costs more then you earn in a month, of which you only will ever want one piece anyway, or write yourself".
After having seen similar "campaigns" from Microsoft and Apple before, I think I can safely paraphrase the above slogan as
Creating monopolies
We spam as much as we want.
Well, there is also good news for the graphics artists out there:
You can get Gimp for free, even on the Mac.
You see, Adobe forgot a teeny-tiny thing. They don't like open source, they don't endorse open source, and they close their eyes in the hopes that if they ignore it long enough it will go away. How 'bout we go away instead. From Adobe. Somewhere more pleasant.
For example, instead of going to the Adobe's "all young artists are belong to us" conference, why not attending Libre Graphics Meeting (http://www.libregraphicsmeeting.org/) instead, and learning of the newest and best in free graphics applications.
Also, Knoppix live DVDs contain many of the free graphics tools in one package. You don't even need to install them. Just download the disk image, burn the DVD (or buy it from a store near you, for example from on-disk for $5.99,* pop it into any computer that can read it, and go. The boot process is lengthy, but it will normally not ask you any technical questions, detect all your hardware automatically, and it doesn't install anything on your hard disk, allowing you to just play with the software at will. If there's nothing you like on the disk, just throw the DVD in the garbage (or erase the rewriteable) and never think about it again. It had cost you $6.
Unlike buying into a medium-size cattle farm called CS3, where you will have to pay for an upgrade every time they build a shinier fence, and also can't give it back once it's open. Which does sound suspiciously like a can of spam. Except, that, too, can be had at a much lower price.
Which reminds me: I know that every wannabe "direct marketing" company out there and many short-sighted small IT corporations that benefited from the original increase in public awareness will try to convince you that I'm wrong. A couple of studies though (for example "The effect of direct advertising to the dearly departed" ) show that spam is indeed not all roses. Most of the IT recognizes spam as a problem. 80% of all the email traffic is spam. And yes, we do pay for it. Even if you don't pay per time or per bulk any more, it is still included in the cost of your "flat rate" and prevents your provider from offering you a better price.
And also... When was the last time you heard somebody say that he was happy to receive a spam mail?
So what is the morale of this little story? Things have changed. Adobe just commited something that in parts of the world constitutes a crime, and waved "all your base..." in our faces. I just lost my last bit of respect for a company that at some point did manufacture quality software, after wasting half a day bitching about it, and added it to my spam filter. And you, my dear reader, might discover a bunch of powerful, new and free tools. Benefit for Adobe so far? Zero.
Case closed.
* - If you order the Knoppix-DVD, watch the version -- the newer, the better / the latter versions of the graphics software you'll usually get. It should be minimum Version 5.1.1 (as of the 4. of April, 2007).
- If you download the disk image, look that it fits to your architecture.(32 or 64 bit, etc).
- If you have trouble with Knoppix, try Ubuntu.
- If you already use Debian, or another linux distribution you can install many of the free tools using your package manager, e.g. aptitude on Debian. Just look through the "graphics" package :)
PS: Useful information about spam (the electronic variety) and how to deal with it, can be found here: www.stopspamhere.ca
Saturday, March 31, 2007
Hello Blogger!
As a long-standing coding tradition requires, this is a "Hello World" post. It doesn't really say anything, it doesn't contain any really useful piece of information, and it also doesn't really show us anything except for how a program written in a particular language looks like from the outside, but we do it anyway - again, and again, and again.
As it is also a long-standing coding tradition, the rest of my blog is probably going to be a lot less polite, contain a certain amount of profanity, annoy quite a few people reading it, be riddled with spaghetti thoughts and pieces from my other blogs, and end up a horrible mess after a year or so.
But, unlike with code, it will hopefully be a much better read.
As it is also a long-standing coding tradition, the rest of my blog is probably going to be a lot less polite, contain a certain amount of profanity, annoy quite a few people reading it, be riddled with spaghetti thoughts and pieces from my other blogs, and end up a horrible mess after a year or so.
But, unlike with code, it will hopefully be a much better read.
Subscribe to:
Posts (Atom)