While the publication InfoWorld was certainly not responsible for my success in the information technology (IT) business, it was arguably the jet fuel that pushed my career into the IT stratosphere. I needed InfoWorld, or something similar, to bridge the gap between IT neophyte and IT guru. I still do not consider myself an IT guru but assuming it could be objectively measured, I am confident that I am in the top 10% of IT talent. InfoWorld was instrumental in helping me get there. That is why I always looked forward to my weekly copy. I never equated reading InfoWorld with a chore. I viewed it as fun. From the irreverent Notes from the Field column by Robert X. Cringely (who is not an actual person, just a trademark) to top notch columnists like Brian Livingston, for much of the last couple decades InfoWorld was my essential publication for staying ahead of the IT curve.
I say “was” about InfoWorld but its staff would say, “is”. InfoWorld is still around. What has changed is that it is now available only online. Its last issue, with “Final Print Issue” all over it, arrived in my mailbox early last week. Dated April 2, 2007, I at first assumed it was an elaborate April Fool’s joke. After all, InfoWorld has been around since 1978, when it was known as Intelligent Machines Journal. When it was sold to the IDG Group (which offers a plethora of IT publications with the “world” in it) a year later, it became InfoWorld.
I stumbled upon my first copy of InfoWorld around 1987. Someone had one lying around the office. Whenever I found upon a copy, I would read it cover to cover. It was not long before I decided I needed to get a subscription, which was free. There was only one problem: it was free only if you qualified. I was a poor computer programmer making $25,000 a year, an IT nobody. Consequently, InfoWorld was not interested in giving me a subscription. They wanted people who made decisions and exercised budget authority. For years, I tried without success to get a subscription. One year I suddenly qualified. I do not know if it was because of the progression in my career or, like many subscribers, I stretched the truth a bit in order to qualify. InfoWorld became a precious gift that kept on giving. It was the best bargain out there for a knowledge craving IT person like me.
Aside from its fabulous columnists, what was special about InfoWorld was that it was always just ahead of the curve. It was a gloriously nerdy magazine, full of detailed product test reviews, IT news, and writers firmly grounded in toughest IT trenches. While it would occasionally flirt with the fanciful, it almost always it kept its focus right where it belonged: on the business enterprise. That is where people like me made our living. We had to succeed in the business sphere to advance our IT career. It was a nuts and bolts sort of publication that told me what I needed to know right now to stay on the pragmatic leading edge of IT. While it could occasionally wax poetic on the virtues of the Mac or the Amiga, most of the time, it was focused on wherever the market was at. That was typically the Microsoft Windows universe. Consequently, reading columns like Brian Livingston’s on InfoWorld was a rush. Brian is the author of many of the Windows Secrets books. I never needed to buy his book though. I learned all sorts of secrets about Windows from his weekly column in InfoWorld. However, Brian was just one of a cadre of top tier IT columnists that InfoWorld hosted. These included luminaries like Bob Metcalfe, the founder of the Ethernet frame-based network. If you are reading this, the data arrived through an Ethernet card attached to your PC. You can thank Bob for his invention. I can thank him for sharing his wisdom in InfoWorld for many years.
In the 1990s, InfoWorld was in its prime. It was a frantic head rush of a publication, stuffed to the gills with incredibly relevant IT material. It overflowed with IT information from a boots on the ground perspective. I held on to my subscription as a lamprey holds onto a ship. When I was required to renew, I never dallied. I could not afford to miss an issue. I needed it to stay on the technology edge. There were many computer magazines out there, but InfoWorld was special. I felt it was in a class by itself. I occasionally flipped through other IT journals, but all of them left me feeling they were missing something. However, InfoWorld was always focused on precisely what I needed to know right now to thrive in my IT career.
When necessary I could read InfoWorld and feel like I was keeping up with IT. There were only so many hours in a day. I simply did not have the time to read everything. The virtue of InfoWorld was that I did not have to. InfoWorld was easy and fun to read. I have to don my academic hat to work my way through the dense verbiage and illustrations in publications like IEEE Computer. You did not have to be a rocket scientist to understand InfoWorld, just an IT enthusiast. All you had to do was keep reading it regularly. Eventually you picked up all the acronyms and buzzwords and could put them into an applied context. That was when you felt you had arrived.
Unfortunately, the real world hit InfoWorld. Two events coincided: the Internet and the end of the technology boom. The Internet pushed more content online. The collapse of the tech boom and the consequential dip in ad revenue pulled out its financial pillars. I was shocked when they let go Brian Livingston. Yet he was one of many columnists like Nicholas Petreley who were unceremoniously shown the door. Some of the new columnists were very good, but most could not replace the shoes they tried to fill. Readers expressed their disgruntlement by letting their subscriptions lapse. Still, I held on, hoping that the InfoWorld I used to know would return. Yet the size of the magazine kept shrinking along with the advertising revenue. I should have suspected something was amiss because InfoWorld was becoming more of a brochure than a magazine.
Now its print version is gone for good. The same content is online, but I am not sure I will make it a habit. The virtue of the print publication, as one of its columnists pointed out some months ago, is that it is finite. The problem with the Internet is also its virtue: it is infinite, as well as constantly changing. It was not that InfoWorld has a bad web site; it is that (a) like most human beings I have trouble absorbing lengthy articles online (b) a laptop computer is too big to retire to bed with (this is where I do most of my technical reading) and (c) I need IT distilled down for me. That is why magazines and newspapers exist. That is how they add value. However, by being required to read it online InfoWorld’s hassle factor increased substantially. Yes, I can search the site easily enough, but I cannot efficiently browse it. I still need to have a surface understanding of IT issues, but the way it is formatted online leaves me with zero interest to dig to get the details.
I should at least be glad that forests are no longer being cleared to make sure I get my print copy of InfoWorld. However, InfoWorld would have ended up in my recycling bin anyhow. The best InfoWorld columnists moved on long ago, not of choice, but because InfoWorld sent them packing. I still track some of them. For example, I subscribe to Brian Livingston’s Windows Secret’s email newsletter. Brian recovered nicely from his firing. Indeed, he got the last laugh. He now has more subscribers to his email newsletter than InfoWorld had subscribers when he was writing for their magazine.
I hope that some other company will pick up where InfoWorld left off. I am sure advertisers still want to target me. Give me its equivalent in print form and I will subscribe, as will many others. I suspect that the reason InfoWorld’s subscriber base shrunk in half was because during the last recession they got pennywise and pound-foolish. In effect, they chopped the legs off their own publication. It would have made much more sense to spend money to get back the fabulous staff and columnists they used to have and rebuild their base. Instead, they looked at their balance sheet, instead of their long-term profitability. As a result InfoWorld, for many years arguably the premier computer magazine is a sad shriveled imitation of itself.
Thanks in part to all those years of reading InfoWorld, I am now precisely the kind of reader that they should crave the most. In effect, they abandoned people like me by discounting my need for a quality printed publication in favor of the cheap production costs of publishing only online. Getting rid of their print publication was a foolish decision. If the InfoWorld website is still around in a year, its content is likely to be of marginal value. Unfortunately, it appears the money managers at IDG are still missing the big picture. I thank InfoWorld for all those years of insight and detail. However, they have lost me as a customer.
Sphere: Related Content
April 12th, 2007 at 08:35pm
Posted by
Mark |
Technology |
no comments
Like many of us in the information technology field, my career has been about creating and maintaining information systems. The techniques and technologies used have varied. Until now the process has stayed essentially the same thing. The process is something like this. Get people to put data into a computer. Store it somewhere. Apply business rules to it by writing a lot of customized code. Then spit it out in the forms wanted by various data consumers.
Really, that’s it. It’s doing with a computer what people used to do in their brains. Computers just have the ability to do these things much more quickly and reliably. But of course you have to tell computers precisely what to do and the order in which it must be done. This logic is what we call code or software. While it has not made me rich it has kept me gainfully employed and enjoying a comfortable lifestyle.
There were classically a couple ways to get information into a system. The most often used method at the start of my career in the early 80s was to stick someone in front of a terminal and have them enter data into forms on a screen. They then pressed a key and off the data went, through the ether and into a database somewhere. But there are other ways to bring data into a system. In the old data processing days one popular way was to load big reels of tapes from somewhere else and read them into mainframe computers. Since then we found more efficient ways of recording some information in a computer. Bar code scanning is probably the best-known way.
Once the information is in the system it is scrubbed, processed, compared with other information and placed somewhere else. In other words, it is sort of assembled. An information system is a lot like a factory. Raw material (data) is dumped in at one end. Out the other end comes data on steroids: information. You know much more about something from the output of the system than you know from the relative garbage of facts that fed it. And this information is typically used to add value, such as to gain a strategic or competitive advantage.
That stuff in the middle between keyboard and printer was a lot of usually hand crafted code. At the dawn of my career it was often written in Fortran or COBOL. During the mid to late 1980s it was more likely to be in languages like C, Pascal or PL/I. During the 1990s object oriented programming languages gained ascendance. Instead of C, it was C++. Businesses that ground out client/server object oriented applications used development environments like Delphi or PowerBuilder. Data and the software used to manage these data began to merge into something called objects. Logically the stuff was still stored separately. But conceptually an object let us programmers get our brains around larger and larger programming problems. As a result we learned the value of abstraction. Our programming languages became more ethereal. It became a rare programmer who could actually write a binary sort routine. Instead we call APIs or invoked methods on software objects to do these things.
Toward the late 90s critical mass developed around the idea that data should be easy to move around. Businesses needed simpler ways to transmit data with other businesses. This was one of those “no duh” ideas that someone should have successfully ran with twenty years earlier. Okay, there were ideas like EDI, but they were expensive to implement. Instead with the Internet finally ubiquitous enough to use as a common data transmission medium, a data standard for the web emerged: Extensible Markup Language, or XML. In the process data became liberated. Whether a field started in column 8 no longer mattered. Tags describing the data were wrapped around each element of data. An externally referenced XML Schema acted as a reference to tell you whether the data were valid or not. Instead of writing yet another unique application to process the data, a generic SAX or DOM parser could easily slice and dice its way through the XML data. Using objects and modules built into the programming language of your choice it became fairly simple to parse and process XML data. As a result there was at least a bit less coding needed to put the system together than in the past.
The newest wave in data processing is called web services. Just as XML became a generic way to carry data with its meaning over the Internet, web services provides protocols for automated discovery, transmission and retrieval of XML formatted data. Figuring out the best way to do this is still being hammered out. Protocols like SOAP are losing favor for simpler URL based methods like XML-RPC and REST. We’ll figure out what works best in time. But equally as interesting as these web services technologies are the XML transformation engines now widely available. The XSLT (Extensible Stylesheet Language) specification, for example, allows XML data going or coming into a system to be transformed in an infinite variety of different ways. It can be something simple like converting XML data into a web page with the XML data embedded inside it. Or XML can be rendered into something more complex, like a PDF file or a MS Word Document.
But what does all this mean? The light bulb finally went off yesterday. I was explaining to a colleague at work why I wanted a system I managed to have web services. My team understood the value. Data and presentation could be wholly separated. With data in XML it could fairly easily be transformed with the XSLT engine of our choice into the format that we chose. The effect of this is to markedly diminish the actual logic needed to set up and maintain an information system. The big payoff? In theory, fewer programmers are needed and it should be faster and easier to manage information. But in addition the system should behave more reliably, since less code is needed to run the system.
For example the system I manage is what we in the computer business call tightly coupled. It works great. But it’s just a pain to maintain. The data of course is stored in a classical relational database. To get it out and present it to the user we have to turn it into HTML. Right now we do this with a lot of code written in Perl. Naturally we get lots of requests to add this and delete that and show data rendered like this. And so once again, as programmers have done for a generation, we perform major surgery on our code and go through extensive testing until we get the results requested. But since we are a government system in a non-sexy agency we are grossly under funded. So most of these requests go into a programming queue. Many of these great ideas will be abandoned due to our tightly coupled system and our limited resources.
So what’s really interesting to me about these XML technologies is that we should be able to put together systems much quicker once we have the architecture in place. In addition we should be able to make changes to our systems much quicker too. We could end up with systems that in the classical sense require little programming. This example on the W3Schools site shows how incredibly simple it can be to take data from an XML data store and render it as HTML. Once the XML schema is defined and the template is written in XSLT then rendering it can be accomplished in just a few lines of code. Of course this is a very simple example. But when I think about what sort of effort and time would have been required to render this same result in those pre XML and web services days I am a little awe struck. The productivity potential is sky high.
So I’m starting to wonder: do XML technologies mean that information systems will no longer require any crafting by programmers at all, but will instead be easily assembled? If so this is revolutionary. But the pieces seem to be there. On the output side of the system XSLT and an XML database work fine together at spitting out information in a useful format. There is little or no coding needed here to make that happen. But what about the input side? There is revolutionary news here too. Initiatives like the W3C XForms project are finding standards based ways to gather form data intelligently. We programmers should not have to struggle too much longer with HTML forms, embedded with Javascript client logic and server based scripting logic. XForms will handle the job in an XML way that will minimize coding and markedly reduce maintenance costs.
And so there you have it: all the components needed to construct basic information systems in a generic fashion are nearly in place. Simple data collection and retrieval systems — what I have been doing my whole career — could potentially be done using open standards and without writing a line of code. With an XForms editor we will draw our forms and push it out to browsers and other web-aware device. Input interface: done. Web services can be utilized for the automated data interchanges needed between businesses. To realize this vision may require putting a SOA (service oriented architecture) in place first. A good application server will be able to get the data and persistently store it without much coding. And an XML aware transformation engine embedded in or talking to the application server will take our template of choice and render it in the format and media wanted.
Will programmers no longer be needed to construct information systems? Not quite, at least not quite yet. Few applications are as simple as the one I suggested. And there are hosts of other variables to be thought through, including quality of service requirements that often require programmers. But I suspect that over time we will see that information systems will require fewer programmers. Instead the emphasis will move toward those on the system administration side. Database administrators will still capture and manage data, but they will also tune the database for rendering content in XML. Business rules will move more into the database or into rules engines attached to the application server. The result should be fewer programmers steeped in the mechanics of languages like Perl. Instead we can expect more time spent tuning databases and maintaining business rules. Form data will be designed in an XForms editors. We will use similar tools to render output using XSLT.
Time will determine whether I am seeing the future clearly. But clearly I am not alone since this is the whole larger point of XML technology. Companies like Microsoft have created packages like BizTalk just for this purpose. (Their Visio product is used to diagram the business rules.) It should get easier and become less costly to create and maintain information systems. And over time we can expect that systems will be able to exchange and process data with each other much more simply.
Sphere: Related Content
March 4th, 2005 at 08:54pm
Posted by
Mark |
Technology |
no comments
