Is there anyone out there who still remembers doing machine language? Assembly? Algol? FORTRAN, even? If so, consider yourself blessed. You had to learn how to write tight, precise code to fit into a small amount of memory, sometimes only a few Kilobytes, and squeeze out the most speed that you could. Not only that, but if you were running on the "big" IBM-360 or something of that nature, then the code had to be reviewed by your co-workers and then by your supervisor BEFORE ever running it - sometimes you even had to have a complete model of what you wanted to do before hand.
Today? No models. No reviews. Just a bunch of web-weenies slinging code hand-over-fist just to see what will happen. No design, no thought process. And, when he / she gets through with it the only question asked is, "Will it work?" If the (usually using the 20% testing covers 80% of the situations rule) test cases (let's just "assume" that there ARE test cases) produce the right result it probably will be rushed into production.
And then it happens. Somebody crashes into the system via a "little known bug" in the software. Or, because the testing was not extensive enough, the performance is crap. That's when the "fit hits the shan" and heads begin to roll. All because the business guys believed some young punk salesman (or an old silver-haired fox) who guaranteed them that it would work and perform blazingly fast. (My friend Yaakov Kohen wrote a blog on this a while back at http://yaakov2.mindpress.com on why rulebased and BRMS projects fail.)
"Those who will not learn from history will be forced to repeat it." (Was that Ben Franklin or someone else? Doesn't matter. Probably Descartes or Plato or some other philosopher from the past that our children today continue to ignore.) At point here is that we, the IT guys, the supposed "brains" of the projects, do NOT force the project managers to STOP and actually do the design work first. They (the PMs) come to the geeks and tell them, "We have to have 'something' to show for the past two weeks of work." And thinking is not something that you can show. Gathering data and rules is not, usually, something that you can show. BUT, if you make it understood up front that nothing tangible will be produced for the first 50% of the time allocated for the project (which is usually not enough time to do anything of any consequence) you still be get that same, tired, worn out line from the PM. "What do you have for me to show to the VP or CEO or some other person who controls the purse strings."
Remember when the VP was a geek? And he / she could not only understand what was happening but could ask really good, discerning questions about what was happening? And could keep the CEO off of your back until the time was right? Well, those guys are gone. Now all that we have are nit-wit, MBA bean counters who haven't the foggiest notion of anything that would help the company beyond the next two or three weeks. Long-term goals and benefits always give way to the short-term rewards that are usually accompanied by long-range disasters.
Who stole my spring?? - After a nice 20C degrees day yesterday, I woke up this morning to this:
3 years ago