Thursday, May 24, 2007

The World of Tomorrow Part Two

I wasn't really fair in my last post; I left too much information out of the equation. Here's the premise:

I am convinced that the Fox world's fearful and grudging adoption of .Net has nothing to do with coding. The "World of Tomorrow" referred to a scenario where 30's serials posited great leaps forward in technology and, implicitly, everyone's ability to understand and adapt that understanding. Billy builds his raygun.

Back to our real world. Billy builds his website and plops it on his Win2K3 web server. It fails. Why?

More in Part Three.

Tuesday, May 22, 2007

Sedna and The World of Tomorrow!

A play on words, yes? Think about it, though, "World of Tomorrow" stuff from the early 20th century was all about extrapolating trends towards the future following an idealistic evolution of existing techs.

What really happened was so much different. Why?

Think about it.

Saturday, May 12, 2007

Welcome to Jiffy Tech

This is sort of a banner year for me. June marks my 30th anniversary writing code; September is my 25th anniversary of landing my first professional data-processing job.

I remember having a conversation with a friend of mine over beers back in the mid-80's. He was trying to understand exactly what it was I did and why it paid so well. I thought for a moment and replied that we were the "priests in the temples in the Dark Ages". We were elite because we knew how to read in an illiterate world. But one day, as technology spread, we'd be the new auto mechanics.

That conversation has stuck in the back of my mind for years and I sometimes look at industry and career trends and hold them against that half-joking prediction.

Now why auto mechanics?

I see a correlation between the automotive industry and information technology.

As to cars, from the late 1800's to the introduction of the Ford Model-T, very few people knew automotive technology. Those that did were well-schooled in every aspect of the cars and were paid well for their arcane knowledge. Operating a car required a far more in-depth understanding of mechanics than today. Pioneers in automotives founded large companies to make cars more understandable, cheaper, and more accessible to the masses - the survivors are Ford, Diamler-Benz, General Motors, and others. Studebaker, Willys, and others were competitive for a time but are now long-gone.

Experienced, independent mechanics today are paid reasonably well but a minimum wage high school kid can do most regular service on a car. However, cars are much more complex mechanically under the hood so, paradoxically, mechanics have to be superior troubleshooters than decades ago, before electronics, ABS, fuel injection, et al.

Looking at personal computer-based IT, from the late 70's to the mid-90's we have a parallel. For about a 15 year period, few people grasped the big picture in how to craft a computer application. Those that were successful at it commanded large sums of money. People not in the industry were scared to death of them. The early experts put together companies to sell cheaper computers or more understandable operating systems or languages. The survivors are Microsoft, Apple, Sun, Compaq, and others. Gone, but important in industry history, are Digital Research (CPM), Commodore, Ashton-Tate, and others.

Experienced, independent developers on average are being contracted at hourly rates we would have laughed at 15 years ago. Contract rates for developing in day-to-day businesses seems to be in the $20 - 40 an hour. This is for doing essentially the same work as commanded $50 -150 an hour 20 years ago. Factoring in inflation and other costs, contract developers are being paid probably a fifth of what they were 20 years ago.

And, like the automotive industry, the product has become easier for the consumer but much more difficult to engineer and troubleshoot.

When a network application of mine puked under FoxPro for DOS, it was either because of my lousy coding, a FoxPro bug, or a network error. 95% of the time I knew within seconds which it was.

When the code in an ASP.NET application pukes, if it's not a coding error you are sometimes in for a long, long troubleshooting session. Is it browser settings? Permissions? Database connectivity? Security policy? Much more difficult to assess. And I get paid a hell of a lot less to figure it out.

On the other hand, my teenage son can easily install an operating system and if was hired to do so by a local computer shop I imagine he wouldn't be paid much more than minimum wage.

Maybe it wasn't a joke after all.

Thursday, May 03, 2007

I'd Like To, But....

I got Markus's postcard in the mail this week. Very clever marketing, a personal message about how he could help with converting to .Net. Some people need that help.

There are a lot of folks not happy with aggressive abandonment of Visual FoxPro; folks who I will not name out of respect. But I will say that I am wholeheartedly one of them.

Don't get me wrong, the VS suite is ...err... sweet. Once you have a grip on the framework, .Net apps are almost as simple to clob together as our trusty old VFP apps.

But not quite.

Managed code applications are a real bear to deploy. The amount of times I have heard "it works on my machine" from a developer versus the supposed worry-free builds I have been given that bombed or required special handling has skyrocketed. Simply put, .Net apps don't deploy well in an "install and forget" environment.

VFP apps won't run devices; neither will they work best in a widely distributive environment. But they work great for desktop database apps and nothing, nothing in the .Net world comes close to meeting that.

Perhaps if MS had stuck with WinFS and put local data storage integral to the operating system with programking support I couldn't make these claims. But they didn't.