Tuesday, September 26, 2006
Is the world really flat?
My latest pleasure reading is "The World is Flat" by Thomas Friedman who's known for his keen observations on mid-east and global politcal situations. I first read Friedman's book, "From Beirut to Lebanon" several years ago and liked his writing style and learned a lot about the situation in that part of the world. But so far, this NEW book is about how technology is changing the world in a big way. According to Friedman, the Industrial Revolution was nothin' compared to what's happening now.
It's interesting to read about how the world is becoming a level playing field (flat) because of technology and to think of what we've all been caught up in (technology) from a whole new point of view. One of the cool things about the book is how much more perspective he has because he's NOT in the technology business. Though I think his predictions are a little over the top, I think his assertions that people who do 'plain vanilla' type of jobs have the most to lose in the new era because of how easy it is to commoditize those jobs now. It reminds me of a professer I had at Rutgers for a couple of programming classes. His name was Steven Minsker and he was the kind of guy who would just look at a problem while everyone else was already working on it, then he'd sit down, type in all of the code and it would run on the first try - long before those who started before him even got close. He used to say, "You know Mike, you can teach a monkey to program". Then he'd turn away, leaving a lull in the conversation and then he'd turn back and say, "But it would be a waste of a perfectly good monkey." I think about that a lot when I hear how programming jobs in this country are being outsourced to Bangalore, India. They have very good schools in India and an aweful lot of people vying for plain vanilla jobs like writing code to satisfy the requirements already set out as class diagrams, user scenarios, unit tests, etc.
Why am I not worried? To me, programming has always been the easy part of developing software. It took a long time to learn how to do it, but a lot of people could do it and still a LOT of projects failed. When I started my first business, a consulting business for both hardware and software (well before Windows or the Internet) that later turned into a software company, we used to say that what we did was turn technology into english. It was never that our clients couldn't ultimately do what was required to get their work done, it's that nobody explained any of it very well. It was as hard to them as setting the clock on a VCR without the instructions. There were no standards for it and the documentation, if there was any, was usually written for technical people. Software development works very much the same way and when I develop software, I bring that translation from what the business needs and wants to the table. I speak the languages on both sides (recently business vs. C# and T-SQL) and bridge the gap. When I think about it, I don't know many programmers who speak business very well and vice-versa. I like the idea of having 4 guys writing the code for the price of 1. I can do a lot more for less that way.
Programmers are not monkeys, and losing jobs is not a good thing for people, but I think that it's time we faced the fact that programming is no longer something so difficult and exotic that it's going to secure us a place in the market. In one way it's freeing us up to work on the innovative side of development and leave the toil to others, allowing us to put in lower bids for new work. My advice is to look at what you do. Is it plain-vanilla work that someone half way around the world can do for less? Chances are that PART of your job is that type of work. Why not look half way around the world and find someone else to off-load that part to? Give yourself a little more vacation...
Posted @ 5:48 PM by Yeager, Mike E (firstname.lastname@example.org) - Comments (1)
Wednesday, September 13, 2006
VFP Conversion Tools
One of the great things about my job is that I get to work on different projects and do different types of work. Sometimes that means I don't write a single line of code for weeks and that's OK, but it sure feels good to get back to it! I've recently been working on tools that convert applications from one development environment to another. In this particular go around, the tools are specific to Visual FoxPro and SQL Server.
I got a really interesting assignment a few months ago to create tools that dig into the proprietary format of Visual FoxPro's screen and report files and convert all the hours, months and years of hard work found in there into .NET equivalents and for reports, into the relatively new SQL Server's Reporting Services format. For the coding portion, I focused mainly on the reports and data environments while a co-worker focused on the forms. The vision and architecture for the project was to take the proprietary information and first convert it to a neutral, intermediate format. In our case, Markus Egger defined a specification within XAML and turned me loose. I used the source code from a couple of existing utilities to "decode" the proprietary format and actually created a class called the FrxDecoderRing, full of constants and static methods to easily convert the information I dug out of the FRX files into standard units and discernable attributes. It was FUN! The way FRXs were created and used was fascinating and close to brilliant for the time period in which it was created.
Once I'd created a few XAML-like files, I got to dig into Reporting Services and the RDL specification. It really is a cool technology and I'm fascinated by how much you can do with it, even though I found the syntax, shall we say, verbose. A simple report represented in 30 lines XAML converts to about 250 lines of RDL - another flavor of XML, mostly due to the somewhat elaborate use of containership. Still, once you get the hang of it, most of the work is done programatically, so aside from being a little harder to read the raw format, it's also easy to work with. The more work I do in Reporting Services, the more I realize that the reports I am converting only use about 20% of what Reporting Services can offer. For example, it only takes a few minutes to add drill-down capability to a report once it has been converted. Pretty cool...
In a way, I can't wait to add more pices to the conversion puzzle. Perhaps the next step will be converting from XAML to ActiveReports. Perhaps it will be converting Crystal Reports to XAML. For now, I'm creating UIs for these tools. One as a command line utility, one as a workbench type of tool for developers so that they can see into the process as it happens. The most recent was a WinForms UI to convert entire folders full of FRX files into .RDL files and test the conversion process en-mass, converting hundreds of reports at a time and then comparing the original to the converted. Occasionally, I find a new tweak that I can make to fix something that didn't come out exactly right. It's very satisfying work. Maybe I'll get to do a WinFX UI for it now...
In my initial efforts, I manually converted reports to see what the converted version would look like. They took several hours each and seemed to always have some slight differences because I didn't line something up quite right or pick the right shade of a color or some other detail. Now the ouptut is identical on almost all reports and I can convert them at a rate of about 100 per minute and the process is so easy, my 8 year old son can do it (to be fair, I'm convinced that he's smarter than I am anyway <s>). Do I have a feeling of satisfaction? You bet!
I've got to go now, WinFX is calling me....
Posted @ 9:49 AM by Yeager, Mike E (email@example.com) - Comments (6)