Saturday, August 30, 2008

Should I.T. shops test with production data

On this day, 11 years ago, Aug. 30, 1997, I drove west to a “new life” in Minneapolis for six years, after a corporate transfer. It was a happy time, and I even took the indulgence to buy a dressy blazer off the turnpike in Fort Wayne, Indiana.

I think now how much information technology has changed since my “good old days”. In fact, I can walk the clock back further, to September 1, 1987 (a Tuesday that year I think) in Dallas, when I was working for Chilton (now Experian via TRW) and when we ran a full month of parallels of old (assembler) and new (COBOL and Datacomm-DB) daily billing systems, printed all the reports, and put them on a work room. We checked every one and kept them, in print. Then, years later, I’d keep lots of production parallels and listings (and File-AID file-file compares) in binders in my cubicle as “proof” of my own testing of elevations.

Although I haven’t worked in this field officially since Dec. 31, 2001, I can well imagine that work habits have to be much different now, because of the corporate risks of consumer data loss. When I was working, that issue had (even by Y2K, when we ran and saved beaucoup detailed production listings, but eventually shipped them to an iron mountain) not yet received significant media attention.

Now, it seems like it would be risky to depend on production data for QA tests, or at least to let programmers work with it. Whole new testbed layers would have to be built, to scrub production data and make it fictitious, but still represent all the test paths and conditions. Whole teams would be needed for this. Major financial institutions owe the public nothing less than the effort to build these teams. And, by the way, they might create some good old-fashioned IT jobs (in QA) along the way. Who knows, maybe there’s an IT resurrection for me yet.

Oh, yes, I remember a joke from the 1987 parallel. "If it works, it's production. If it doesn't, it's a test." No more.

Wednesday, August 27, 2008

Another anniversary: lessons learned from a 1991 mainframe elevation on this date

I do like my own personal anniversaries, don’t I. Today is August 27. On this day in 1991, although it was a Tuesday, I made an elevation at work that would live, not in infamy, but would at least set the tone for work life for some time to come. There’s a moral tone, and a lesson for a new generation of IT people, perhaps.

We had a salary deduction billing system written in COBOL and IDMS (with VSAM transparency), that printed out separate bills to mail to employer-clients. The project was to stack the bills and make them easier to mail, eliminating the need for one or two clerical positions in the user era. (Yes, even before the days of kiddie entrepreneurs in dorm rooms, IT professionals were in the business of eliminating jobs, while creating new ones). We actually ran only three more bills that day after the elevation (we called them “moves”) but the next day, it took ten hours to get through about 100 bills. (We called them “The Bills” which became more controversial than the much more complicated but corresponding collections system.) With technology available then, the contention with multiple jobs going against the VSAM file (despite SHARE options and configuration) was crippling. Once in a while one would crash because of the contention. The transparency did not work perfectly.

In time it got better, and two years later no one thought anything about it. The processor improved (we had IBM MVS emulated on a Hitachi machine), operating system changes improved VSAM and even disk access. By the end of the 1990s, and after a move to Minneapolis, the same mix of jobs could start around 5 in the morning and finish easily in less than an hour. No one gave it a thought. The system faded into corporate obscurity.

What I understand is that same experience occurred for programmers who learned the Vantage administrative systems for life insurance. In the early 1990s, the cycles took forever to process even 50000 policies. There was a competitor, VLN (with a similar technical approach), from San Antonio, whose software vendor went out of business. Vantage processing greatly improved in the mid 1990s, and Vantage would rule the world. Now it is a sought-after skill in an otherwise sporadic mainframe job market.

There was another part of the story. In the early 1990s, we had gotten CA-Librarian, and were not always careful to enforce a rule that a source element had to be manually locked ("processed") before it was elevated. "Data control" did try. (I remember some screenplay-like dialogue: "Moves!" "Rejects!"). If that rule was not followed, source-load-module integrity could be compromised. Later, automated procedures (was with Harvest, Changeman and Endeavor) would enforce that rule.

Monday, August 25, 2008

What's "wrong" with I.T. as a "career"?

Jason Hiner, on his Tech Republic “Sanity Check” blogs, has an interesting perspective today on five things that are “wrong” (he uses a less nice word) with information technology as a profession. The link is here. There are a few points well worth noting.

Yes, if you say you are a geek and not a socialite, people really expect you to play the part. You’re supposed to be able to fix anything, say with your home’s network router, when what you do at work is program COBOL. People gawk and sneer, and call you “professor”. They really did that with me in the Army in the late 1960s. That’s one reason why companies like IBM and EDS said, back in those days, that they needed “Molloy” dress codes, complete with stocking garters.

Another thing is, yes, you have to keep getting yourself retrained, and often at your own expense. Sometimes it’s necessary to travel and separate yourself from your life and focus.

But the real problem was the way the job market behaved. The “market demand for one’s services” could behave very much like a home price. The “war for talent” in the 90s became a bubble, that burst (and not just in mainframes) after Y2K. Hiner mentions offshoring and the H1B Visa issue. These matter, but part of the issue is that, typically, techies value their independence so much that they just won’t organize, so employers can divide and conquer, and treat them as disposable. There is a real trade-off between “hyper-individualism” and “solidarity” and it takes on moral dimensions.

Now, of course, we have the “reputation” issue. Employers want contractors who are “professional” in some narrow expertise area (which, surprisingly often now, can be mainframe-related) but, in this Myspace and Facebook age, individual professionals are unwilling to invest in a “reputation” that itself can evaporate like water ice on Mars in direct sunlight (not just off-shored, but off-earth – some day we’ll have to deal with that!)

The “independence” of techie-people leads to another problem, too, the long hours. Typically, they are salaried and put in infinite overtime to keep systems running 24x7. The hours are more irregular now than they were two or three decades ago when most of the online activity took place during business days on mainframes; now the end users are often home users. Technology is often thought of as not a good career for someone “with a family.” But, come on, then, what about medicine, nursing, the military?

I remember writing a short term paper for a Unix course at Northern Virginia Community College in 1995, and having to deliver a short talk, on "the job market for computer professionals". In those days, it was the "hands on" people who kept their jobs.

Sunday, August 24, 2008

REM Sleep workout for a contracting job

Well, I don’t know if it’s legitimate to say that a REM-sleep dream generates news, but last night I had a dream about what a return to work in I.T. could be like.

Somehow, I had a “work from home” job, telecommuting, writing little pseudo-conversational CICS programs to handle SEND’s, RECEIVES, VSAM updates, and user edits. But the job was timed more like what it would be for a reporter having a newspaper deadline to get a story in. I would not be able to completely test the transactions through some sort of PROCOMM emulator, so I would go ahead and promote them anyway through some kind of Changeman or Endeavor script that would come up. I would just hope for the best. Then an hour later or so (probably only a few seconds in real time – this was a dream, after all) I’d get a call from the boss scolding me for messing things up. I would get one more chance if I was to keep my job.

They say that in dreams you dress rehearse for future life’s activities. Maybe “dreamcatcher past” is prologue here.

Of course, there would be another consideration in such an arrangement. My machine would have to be clean, and not used for anything but “work.”

Back in 1985, a couple weeks before an implementation at a credit reporting company in Dallas with a large assembler project, I remember a woman told a story about a dream in which she got a pink slip, saying that she and I had been fired, and the boss demoted. Reason: "BA165". That was the name of a controversial assembler program, with lots of BAL code off R15, "out of addressability." All in an August endsummer night's dream, without Felix Mendelssohn.

Tuesday, August 19, 2008

SEC will require companies to file online using markup language called 'XBRL'

The Securities and Exchange Commission (SEC) will soon require that all publicly traded companies and mutual funds file their reports online with XML-based software called XBRL (Extensible Business Reporting Language). Financial reports online constructed in this manner will make it much easier for analysts to quickly figure out what is going on with a business, especially a new one.

The basic link for the software is based on the name, here. There you can quickly link to a specification document for XBRL 2.1 and see Recommendation-2003-12-31.

Information technology courses in XML will probably be modified to include this topic, which is likely to be taught in universities and by corporate education centers as a separate topic. I took a course in XML at Hennepin County Technical College at the end of 2003.

A relevant component would include the XPointer Framework at W3C, link here.

The Washington Post this morning (Aug 19) has a story by Christopher Twarowski: “Financial Data on ‘Steroids’: SEC to Junk Paper Filings, Require Interactive Online Reports,” Business Section, link here.

Will the SEC’s promotion of the product lead to a sudden gold rush of jobs in the area?

Thursday, August 14, 2008

Employers debate whether to use or ban "social networking" sites at work; Twitter can actually help monitor customer service

Eweek has an article about a reported tendency for more companies to ban use of Web 2.0 tools like Twitter, or Myspace and Facebook on work computers. Much of this has to do with security concerns, or numerous media reports of abuse of these facilities during social networking. Some companies approve of LinkedIn, SharePoint, or Lotus Connections but not the more “popular” sites.

Eweek has an article by Gartner analysts Anthony Bradley and Nikos Drakos discouraging this “draconian” practice, link here. The report is titled “Gartner analysts decry Facebook, Twitter bans at work.”

The quote young Facebook CEO Mark Zuckerberg as saying “Facebook is about sharing information. Why would we ban it?”

Drakos has once participated in a mock debate arguing that companies should ban “social” networking sites at work. He did make the point that, if an employee names his employer on his Myspace or Facebook profile and then presents himself or herself in a negative fashion (you know, the wild party problem) that could affect the entire company’s reputation.

The second page of the paper is “why companies should be cautious about social tools”.

Furthermore, remember that some companies like Comcast and other telecommuncations providers are using Twitter to monitor their level of customer service. I had discussed this on my main blog here, July 22.

Tuesday, August 12, 2008

What are the "dress for success" rules now?

Tori Johnson, career consultant on ABC’s Good Morning America, conducted an experiment this morning with another female consultant doing a job interview with straight hair v. curly hair. The results were interesting. The report said that while women often find straight hair preferable in “finding a mate,” curly hair seems to peak more interest among employers in a team job interview, even if the employers say they felt “annoyed.” Straight hair was preferred by employers ten years ago, but not now.

Outside of the media, there is always a controversy on how much people should spend on appearance for the job. In information technology, in many cases, people (especially younger people) did well with a fun appearance, or sometimes (older people) with a plain appearance that did not appear costly. In other professions, it seems like there is a definite emphasis on impressing or manipulating the customer with sartorial tastes.

Of course, back in the 1960s and 70s there was a lot of controversy over dress even in I.T., when the field was newer. IBM and then, notoriously H. Ross Perot and EDS, created a lot of buzz with strict dress codes, that at one time even including long stockings and garters for men (with inspections. Later, the code emphasized a dark suit, and white shirt, with codes kept on at all times when around the customer. Narrow ties were conservative, but in the early 1970s wide ties came into fashion as did flares and bell bottoms, even with suits. ). I once saw one of EDS’s 1972 memos, which seem to emphasize the fact that dress was important to keep the confidence of customers who did not understand data processing. John T. Molloy wrote his “Dress for Success” books that tailored advice to regions of the country, and even suggested that young men needed to add gray to their hair to look older and more “authoritative.” The pretentiousness (and cover-up) seem offensive by modern standards.

In a tight economy, I'm not one who would like to spend money frivolously on appearance items just to pander to a employer's subconscious sense of fashion.

Monday, August 11, 2008

Retirees and the financial services industry: more analysts needed?

I get a particularly challenging question sometimes. “If you spent twelve years earning a good living from the life insurance and annuities business, even as a computer programmer (individual contributor), then why don’t you want to sell it now? Why don’t you want to justify your life for the past umpteen years? Is this a reenactment of Albert Brooks’s 1991 film “Defending Your Life”?

I understand where the financial services industry is. Even with all the layoffs, they could use the maturity and business knowledge base that someone now in his 60s might have built up over many years in an industry. Of course, the problem is the business model. To compensate the person, they have to base it on commissions and sales. So they need someone who has the social contacts (and can use them to generate more leads) to bring in the business.

The problem is that a lot of tech-savvy people are introverted, and don’t like to manipulate people. Call it a discussion of “The Polarities” if you must. Now, we’re starting to see this more in the baby boomer population as it ages into post-pseudo-retirement second careers. Another potential problem in some cases: non-compete clauses, or various other conflict-of-interest provisions; sometimes pensions have non-compete clauses, too.

The Internet has created a culture of “do-it-yourself” insurance purchase and financial planning, without people. But there is no question that there is a legitimate need for human beings to sit down with clients and go over options in a complicated environment, especially with newer products to deal with troubling issues, like long term care insurance.

Perhaps the financial service industry, out of enlightened self-interest, even as if picks up the pieces from the current credit crisis, can contemplate its need for mature business analysts who can sit with clients in-house without having to go out and fish for them. And perhaps they can be paid hourly. We shouldn’t have to “always be closing.”

Thursday, August 07, 2008

Learning curves: from FORTRAN and COBOL to OOP's, and then some

I know I’ve touched on this before, but I keep coming back to the question, why was making the “switch to client-server” in 2000 and 2001 difficult, with such a rocky learning curve.

I can recall the steady experience of learning FORTRAN in government (civilian Navy department) summer jobs in the 1960s, and the ease of learning COBOL procedural programming in the 1970s. When I went to work for Univac in 1972 in site support, I was originally the processor support point person for FORTRAN. I was assigned for a time at the account at Public Service Electric and Gas in downtown Newark, NJ, which at the time used a lot of FORTRAN. That’s where I started the switch to COBOL. When I went to NBC (in Rockefeller Center in New York) and worked in general ledger, I found COBOL very easy to pick up. It took longer, however, to learn the proper coding techniques and practices. At the time, the concepts of “structured programming” (GOTO-less) and “top down design” were just evolving. The accounting system that we purchased, from Infonational, had source code with lots of GOTO’s (particularly the general ledger year-to-date merge).

I didn’t get exposed to Object Oriented programming and java until 1999. I started with an off-job-campus course in suburban Minneapolis from one of the many training companies in the area. A week isn’t quite enough to immerse you in it. When I started working in the area, it was mainly in support. We also had in-house courses in UML (Unified Modeling Language). There was also an off-site week-long course in Powerbuilder, which managed the GUI layer. But the way to learn this, like learn anything, is to develop and implement a project and be responsible for it afterwards.

But we learn that teenagers seem to sop this material quickly. Modern “open system” skills, as they developed in the early 1990s, seem “non linear” when you learn them. It seems that learning them is like learning to play a musical instrument. When do people learn music skills? Usually as kids. This sort of thing is easier to master before your brain finishes its biological pruning process (making itself more efficient) at around age 25. So, just as you find early teens with phenomenal abilities in music, some of then accomplish phenomenal feats before age 20, inventing (in C++ or java code) whole new business concepts like Napster or Facebook, not always aware of the social or even legal consequences of what they will deploy (that takes more maturity and “consequence judgment”). Someone in his 50s might invent a conceptually new way to handle the news (like my “do ask do tell”) but will not be able to code a whole P2P music download application in 60 hours alone with a laptop.

Career coaches and outplacement counselors sometimes say that much younger people are very quick and getting things done, but sometimes it’s the wrong thing. Older workers may have more judgment as to the appropriateness of what is to be done. That’s an interesting balance in the job market.

One other rambling comes to mind here. That is, how quickly java became a standard production environment. Java was invented in 1991 but not implemented for public use until 1995. Yet, by 1999 the financial services company for which I worked was writing a mid-tier data access layer in java, fully confident. (I didn’t get to work on this until 2000, and then just in support – I remember the controversies over “thread death”.) By 2000, Sun had developed its certification programs fully, with textbooks hundreds of pages long, demanding that programmers master arcane skills probably not used in a lot of shops. It’s amazing that this developed so quickly.

Wednesday, August 06, 2008

Online reputation, and the public exposure inherent in many jobs: where am I personally headed?

Recently, I’ve made some more posts on my main blog about employer blogging policies, especially in news organizations, and on online reputation. On this specific blog, related to the IT world, I’ve expressed concern that staffing organizations could become concerned about online reputation of contractors that they send to other clients.

Generally, one major issue in the workplace is whether a particular individual is known, by name and identity, to stakeholders outside the organization, and whether that person is perceived as representing the organization publicly or making decisions for them, or even making decisions about clients. Different career fields can have special issues. In the formal media world, companies have to make sure that the public believes that their journalists will remain objective in reporting. In the insurance world, companies might have to make sure that underwriters don’t allow personal beliefs affect underwriting decisions. Almost anywhere in mainstream corporate and even government America, employers have to be confident that personal beliefs don’t affect personnel actions (and that can be tough).

Another issue is compensation. For a few decades, programmers could work internally in many large companies (especially financial institutions) and command quite ample salaries while remaining “private” to the company; as we moved into the Internet age, employees in these situations generally believed that they could say what they wanted on their own dime, as long as they didn’t betray confidences or trade secrets. The market seems to have changes, especially since 9/11, as companies have outsources IT and the contractor-client model, set up by a staffing company, becomes relatively more important. (Actually, this model had gotten fairly well developed in the 1980s.) Generally, it is becoming difficult to be compensated well in a job where one won’t be known externally and quite publicly by what one does for a living. One good example that supports this are repeated reports that the demand for technical sales people is strong, but many "technies", perhaps often introverted, don't like the social schmoozing expected in the sales world and see some of it as fake.

Think about it. When I worked as a debt collector in 2003, I used my first name only. Clients didn’t know who I was. And I made only $10 an hour (still living off a “retirement” settlement from my IT career). I thought about becoming a USPS letter carrier – at $17 an hour. I was approached by many parties to “sell things.” Most of these were pyramids of some kind that would probably last a while and then collapse. Think how I would feel now had I sold subprime mortgages. I could have.

I have looked at becoming a financial planner or a tax preparers. In this case, you have to get your own clients by using your social life, you have some sort of personalized relationship with each client, and you need to have your clients’ best interests at heart. People who do that shouldn’t be sounding off in public about the “unfairness” of public policy, most of all the tax code. (Maybe they could get away with saying “end the income tax and replace it with nothing”, like the late Harry Browne.)

I substitute taught, and considered investing in the time to become a full time teacher. I would certainly relish teaching AP calculus, and could get my math back up to buff. I really could. But there are “role model” issues that I have detailed in the other blogs (too much to cover right here).

I still do get questions now as to what I will do personally about this, at 65. That is difficult for me to pin down, at first. There is no question that a job that would require me to become visible through the job would require me to change my personal online behavior (ah, “reputation defender” again) and squash the expression of some ideas that are important to me. Or maybe it wouldn’t. A lot of it has to do with the public goals associated with the job. Do I want to be remembered for helping wealthy people pay fewer taxes? No. For helping same-sex couples beat this system? Maybe that’s a little better. For helping overturn “don’t ask don’t tell” or COPA? That’s getting warmer, although that doesn’t seem close to the purpose of most mainstream employers. (Well, maybe the COPA part – or particularly the related idea of “implicit content” does. A job where you have to bring law and technology together is more in the ballpark.) How about something like, helping a major search engine company solve the “spam blog” and “false positive” problem? I think I could contribute something there, and would feel publicly proud to have done so. There are issues in Internet companies, with business models, sometimes related to advertising or often to the potential for abuse, where technical solutions and redefining the business model or strategy can turn out to become as important for the free speech opportunities for individual citizens as any court opinion or law. I know that from my experience with libertarianism. At least, here, I’m mapping out some strategic planning for myself.

Friday, August 01, 2008

Elance is an "Ebay" for job contractors, customers

NBC4 tonight in Washington DC told viewers about a new site for efficient outsourcing of work, called Elance. It is sort of an employer’s “Ebay” but it is also intended for individual consumers of services. The vyline is "Find Professionals: Get Your Job Done." There website contains a short video by Timothy Ferriss, author of “The Four Hour Workweek” (Crown, 2007). One concept seems to be taking the idea of “piece-work” pay to its ultimate end-point.

Apparently it provides a way to test or interview the “job applicant” and collect customer comments about his or her “reputation.” (Yup, here we go with “online reputation” again.) It also provides for secured third-party payment, and only after the customer has verified that the work is completed.

This sort of service might work well for some kinds of web-design projects, custom design, or unusual troubleshooting of complex applications (perhaps even music and film-editing applications).