Ok, now I am trained up to be a Business Analyst, and an opportunity to be one was about to present itself. But first, a little about changing environments.
When I joined and for the first few years I was there, Crown was PL/1-IMS mainframe shop with all systems developed in-house. I don't know how this came about, as so many companies used COBOL and VSAM files. The fact that Crown Life did not use COBOL was one of the reasons I accepted their job offer in 1979. The only old war story I heard from some company veterans was when the first computer was installed at the company in the mid-60's. It was a big deal, all about "turning the big switch" to move the company on to using a computer.
Development of new systems moved in cycles, of course, depending on what needed built/replaced, allocation of budgets, etc. After the development of the new Stocks/Bonds Admin system was done, the focus moved to the Group Insurance business. Crown Life did a lot of business in the United States, like most Canadian insurance companies of any real size, and it was still possible to make money in group health business as well as life, before health costs sky-rocketed and HMOs took over.
So, the company had a number of group sales offices around the United States doing business, and they needed a new system. Something about the cost of using billable mainframe cycles probably played a role in the decisions to create a system based on a mini-computer located in each sales office, which employees would use all day, and each mini would then feed the days transactions to a master system on the mainframe in Toronto for consolidated processing; sounded reasonable, I guess. Adding minis to our mainframe environment was new, and probably should have been treated as a risk, but I was 26 years old and not on that project, so can't say I worried about it much myself.
The team for this project was located next to the department I was in. I recall that I did not know many of these people directly, but they seemed like a good enough bunch. Reporting about project status to people outside the project always presented things in a good light, but that kind of reporting usually does, no matter what is actually happening.
Because something bad was happening on that project; I found out about it like most of the rest of the company when I came to work one day and the area with that project team was empty, and stayed empty. The mini-mainframe mix had not worked out (more on that later), so the project was cancelled and the whole team up to director level was let go, fired. I don't believe the 'down-sizing' euphemism had been invented yet, but this was the first one I ever saw like this, quick and brutal. I think this was the cause of me realizing what a lot of other people were realizing as the 80's progressed: companies could just not afford to be completely loyal to their employees, so it was time to start managing your career yourself, start looking out for #1. Obviously this is when employee loyalty to their employers started to disappear too, and management magazines over the next 10 years or so had to gall to print articles asking "why?".
Anyway, the Group Business division still needed a system, so senior management brought in a new team that went right out and bought a Group Insurance COTS package. It was totally mainframe, so whoever wanted to avoid mainframe costs was ignored (or had been one of those who was fired), and it was COBOL-CICS-VSAM.
This was the first package I had seen purchased at Crown Life, so the developing of all systems in-house could not be assumed anymore; and the pure PL/1-IMS environment was no more. Business realities would now drive what systems and technologies would be used.
PS: About the reason why the mini-mainframe mix failed... about 5 years later, I was on a training course near Washington DC, and the direct flight for myself and a co-worker also attending back to Toronto was canceled. So, we ended up on a travel nightmare, taking a flight that stopped 3 times and we had to change planes once. A couple of other travelers were doing the same thing, so we got to talking (especially in the bar between planes) and turned out they were AT&T techies. When I said we were from Crown Life, they rolled their eyes and said that we may not want to hang out for the rest of the trip.
Why? It turns out that for the minis in those Group offices to communicate each night with the mainframe, they would need special or dedicated lines (any network techies reading this will probably know why). In those days, those lines were not easy to get, and Crown Life ended up on a waiting list measured in years. When that situation became apparent to all, it wasn't too long after that I came into work and found that project team gone.
PPS: Crown Life apparently sued AT&T over this. They had a contract, of course, and they claimed the delays breached the contract or something like that. As a Crown Life employee, I never heard about this lawsuit, but the AT&T guys we were traveling with sure had; I don't know how the suit ended up, but Crown Life was not a favorite of AT&T for a long time; but us foot soldiers who had met at random decided we would have a few more beers and not let company issues bother; we just wanted to get home that night.
So, when I started on the next big project, all assumptions had changed.
Tuesday, September 29, 2009
Monday, September 28, 2009
Memories of IT - 1984 - Structured Techniques
So, this many posts in and I am still less than 5 years into my career... but an important shift in the story is imminent.
As I came off pure programming work like the new devevelopment project I have been describing, the Analyst part of my Programmer/Analyst job title started to dominate. Some of it was the work I moved on to, but also a parallel path of training that the company paid to have me attend. Everyone has a complaint or two about anywhere they have worked, but my first employer did understand that training was vital to the development and overall happiness of their employees.
Some of the training was general skills, like public speaking and on giving presentations. On the IT side of things, structured techniques were all the rage, broken into the parts of Structured Analysis and Structured Design. As I was still primarily a programmer, I recall I attended a Structured Design course first; it was given by an external vendor. The actual diagrams and techniques have faded from memory, but I do recall it is where I first learned about"high cohesion" and "low coupling". The course also showed how it used the results of Structured Analysis as input to Structured Design.
So, I continued along, doing enhancement work on existing systems. Understanding what the business wanted out of the enhancement, and then determining the impact it would have a on a system was the majority of the work; the actual programming work needed could often be minimal. So, it seemed like maybe I was turning into an Analyst who programs a little. I think the company did have the Business Analyst job title already, so I veered my career path towards that title.
That meant I got to attend the next offering of Structured Analysis training. The course used one of the era's gurus as a basis for the course: DeMarco or Constantine or Yourdon or whomever. I should have kept my course material, it would be a classic now!
It was on this training I was first introduced to the Data Flow Diagram, orDFD. The idea of diagramming what your system should do really appealed to me, even if the diagrams were hand-drawn and hard to change. Pencils and erasers is what I remember of the course and subsequent work back at the office. That would have caused a lot of people to use it less or stop using it, but not me. My future was being defined right there in that course.
Next time - the next big project
As I came off pure programming work like the new devevelopment project I have been describing, the Analyst part of my Programmer/Analyst job title started to dominate. Some of it was the work I moved on to, but also a parallel path of training that the company paid to have me attend. Everyone has a complaint or two about anywhere they have worked, but my first employer did understand that training was vital to the development and overall happiness of their employees.
Some of the training was general skills, like public speaking and on giving presentations. On the IT side of things, structured techniques were all the rage, broken into the parts of Structured Analysis and Structured Design. As I was still primarily a programmer, I recall I attended a Structured Design course first; it was given by an external vendor. The actual diagrams and techniques have faded from memory, but I do recall it is where I first learned about"high cohesion" and "low coupling". The course also showed how it used the results of Structured Analysis as input to Structured Design.
So, I continued along, doing enhancement work on existing systems. Understanding what the business wanted out of the enhancement, and then determining the impact it would have a on a system was the majority of the work; the actual programming work needed could often be minimal. So, it seemed like maybe I was turning into an Analyst who programs a little. I think the company did have the Business Analyst job title already, so I veered my career path towards that title.
That meant I got to attend the next offering of Structured Analysis training. The course used one of the era's gurus as a basis for the course: DeMarco or Constantine or Yourdon or whomever. I should have kept my course material, it would be a classic now!
It was on this training I was first introduced to the Data Flow Diagram, orDFD. The idea of diagramming what your system should do really appealed to me, even if the diagrams were hand-drawn and hard to change. Pencils and erasers is what I remember of the course and subsequent work back at the office. That would have caused a lot of people to use it less or stop using it, but not me. My future was being defined right there in that course.
Next time - the next big project
Wednesday, September 16, 2009
Memories of IT - unexpected consequences of system development
(Actually, I need to wrap up a few things and start a few others before I get back to PCs...)
So, I came off of the big PL/1-IMS development project, as it wound down, 1983 or so. The system from my viewpoint was brilliant, supporting all the stock and bond investment business of the company. I worked a lot on look-up screens, starting with a definition of a security and breaking it down to all the lowest levels of investments the company had in that security. A friend of mine was quite proud of a program he wrote to allocate bond income across the company's complete portfolio after one hit of the enter key. However, it still faced two challenges:
1. the easy-to-program architecture of the online system did require more of the system to be loaded in memory at a time than an architecture based on a single screen structure. As a result, the online system always had lowest priority among all the online IMS systems, and so response to the users was always slow.
2. the actual securities traders had been doing business over the phone and writing down their trades on scrips/paper, then handing these to clerks to code up transactions to feed the existing batch systems. A major proposed benefit of going to an on-line system is that the traders would now enter their trades directly into the system, giving real-time updates and removing the clerical effort. So, our BA/PM shows a test version of the system to management and the traders, to show just how this was all going to work for them. Apparently the traders weren't aware of this benefit, and they reacted very negatively. Typing anything was for clerks and secretaries, so using a system that required typing was beneath them. So, when the system went live, traders continued to write their trades down and handed them to the clerks, whose jobs continued but as the new users of the online system.
The system did go on to have a useful life of about 10 years. I did not work on it again, so I don't know if the traders ever warmed to it. I do recall some outside consultants doing reviews of our existing systems later in the decade, and they said something stupid about this one; given its volumes compared to say, our core individual insurance systems, they wanted to know why we had not developed it on a mini-computer. I think the architect,s head probably almost exploded. I suppose not owning a mini-computer did not mean anything, nor the fact that that the company's core IT skills at the time of development were all on mainframes. By the time of this review, however, other changes had occurred; packages were being purchased, which meant COBOL and CICS were invading our previously pristine PL/1-IMS world. The architect left the company not too much later. Breck Carter, wherever you are, if you see this, drop me a line.
So, I came off of the big PL/1-IMS development project, as it wound down, 1983 or so. The system from my viewpoint was brilliant, supporting all the stock and bond investment business of the company. I worked a lot on look-up screens, starting with a definition of a security and breaking it down to all the lowest levels of investments the company had in that security. A friend of mine was quite proud of a program he wrote to allocate bond income across the company's complete portfolio after one hit of the enter key. However, it still faced two challenges:
1. the easy-to-program architecture of the online system did require more of the system to be loaded in memory at a time than an architecture based on a single screen structure. As a result, the online system always had lowest priority among all the online IMS systems, and so response to the users was always slow.
2. the actual securities traders had been doing business over the phone and writing down their trades on scrips/paper, then handing these to clerks to code up transactions to feed the existing batch systems. A major proposed benefit of going to an on-line system is that the traders would now enter their trades directly into the system, giving real-time updates and removing the clerical effort. So, our BA/PM shows a test version of the system to management and the traders, to show just how this was all going to work for them. Apparently the traders weren't aware of this benefit, and they reacted very negatively. Typing anything was for clerks and secretaries, so using a system that required typing was beneath them. So, when the system went live, traders continued to write their trades down and handed them to the clerks, whose jobs continued but as the new users of the online system.
The system did go on to have a useful life of about 10 years. I did not work on it again, so I don't know if the traders ever warmed to it. I do recall some outside consultants doing reviews of our existing systems later in the decade, and they said something stupid about this one; given its volumes compared to say, our core individual insurance systems, they wanted to know why we had not developed it on a mini-computer. I think the architect,s head probably almost exploded. I suppose not owning a mini-computer did not mean anything, nor the fact that that the company's core IT skills at the time of development were all on mainframes. By the time of this review, however, other changes had occurred; packages were being purchased, which meant COBOL and CICS were invading our previously pristine PL/1-IMS world. The architect left the company not too much later. Breck Carter, wherever you are, if you see this, drop me a line.
Monday, September 14, 2009
Memories of IT - PC enters the home, then the office
In the early 80's, I was one of the younger people in my department, even with regular new hires coming on. It would actually annoy some people...
However, we would also have co-op students, who went to university for a term, then work at a company like ours for a length of term, then go back to school. The good ones would be invited back for more work terms and often came on permanent after graduating. It was at a work-party hosted by one of these students that I saw my first personal computer. I think it had to be an early Apple, but can't be sure now. Anyway, the main thing it was running and people were trying out was one of those Alien Invasion games: bad aliens dropped from the top of the screen and you moved your weapon left and right on the bottom of the screen shooting upwards to kill the aliens before any got to the ground. Well, I thought this looks like fun, and took my turn to play, but as my previous post said, eye-hand coordination is not my strong point, and you had to use certain keys to move and shoot which I wasn't familiar with, so I lasted about 30 seconds before I lost. The surrounding young folks hooted and basically told me I sucked, so I left the game room, returned to the rest of the party and got a beer. If that was personal computing, I said to myself, then they can keep/stuff it. When the young folks weren't playing the game, they were going on about programming the thing, in Basic I guess, which I thought was mickey mouse; I mean, I programmed an IBM mainframe for a living, you could stuff your toy programming too.
So, all in all, the arrival of the PC was not something I was promoting any time soon; but one day, an IBM PC was delivered and set-up in our department. character-based screen and two floppy drives (A: and B:), and a daisy-wheel printer attached. I have to think that the amount of mainframe cycles and laser printing we were using for documents was seen to be costing too much money, so what about this PC thing for doing that?
First off, many people thought the printer was horrible, still using fold-attached paper fed through a wheel with a print quality barely above that of crayons, so people stuck to their PDS members and mainframe laser printing. The thing that got one person using the PC was Visicalc, the first PC spreadsheet. It was the BA/Manager of the big development project we were all on, and she had to do either a business case or status report with a lot of numbers to calculate and add up; well, she thought Visicalc was even better than sliced bread, and I can see why. There was nothing like it in all our mainframe programs and utilities; she might have been the first person to eventually get her own dedicated PC.
Meanwhile, the rest of us are trying out the PC as encouraged by our managers, so you sit down with at least three 5.5 inch diskettes. The first is DOS; insert it in drive A and turn the PC on. The machine would boot, and I don't recall it taking too long (long boots were still in the future). Once you get the A: prompt, take out the DOS disk and insert your Multimate disc, it being the first PC word processor of any note. So, enter MM or something at the A: prompt and it loads. It was green screen, no graphics, and so you created a document, a blank space to type in. When you wanted to save your work, insert a blank floppy disk in drive B: and save it there…as long as you had remembered to format it using DOS before hand. When you are done, take the third disk with you with your work on it, and leave the other disks for the next user.
Given all this, the PC did not really get a lot of users, but my use of a PC was about increase dramatically.
However, we would also have co-op students, who went to university for a term, then work at a company like ours for a length of term, then go back to school. The good ones would be invited back for more work terms and often came on permanent after graduating. It was at a work-party hosted by one of these students that I saw my first personal computer. I think it had to be an early Apple, but can't be sure now. Anyway, the main thing it was running and people were trying out was one of those Alien Invasion games: bad aliens dropped from the top of the screen and you moved your weapon left and right on the bottom of the screen shooting upwards to kill the aliens before any got to the ground. Well, I thought this looks like fun, and took my turn to play, but as my previous post said, eye-hand coordination is not my strong point, and you had to use certain keys to move and shoot which I wasn't familiar with, so I lasted about 30 seconds before I lost. The surrounding young folks hooted and basically told me I sucked, so I left the game room, returned to the rest of the party and got a beer. If that was personal computing, I said to myself, then they can keep/stuff it. When the young folks weren't playing the game, they were going on about programming the thing, in Basic I guess, which I thought was mickey mouse; I mean, I programmed an IBM mainframe for a living, you could stuff your toy programming too.
So, all in all, the arrival of the PC was not something I was promoting any time soon; but one day, an IBM PC was delivered and set-up in our department. character-based screen and two floppy drives (A: and B:), and a daisy-wheel printer attached. I have to think that the amount of mainframe cycles and laser printing we were using for documents was seen to be costing too much money, so what about this PC thing for doing that?
First off, many people thought the printer was horrible, still using fold-attached paper fed through a wheel with a print quality barely above that of crayons, so people stuck to their PDS members and mainframe laser printing. The thing that got one person using the PC was Visicalc, the first PC spreadsheet. It was the BA/Manager of the big development project we were all on, and she had to do either a business case or status report with a lot of numbers to calculate and add up; well, she thought Visicalc was even better than sliced bread, and I can see why. There was nothing like it in all our mainframe programs and utilities; she might have been the first person to eventually get her own dedicated PC.
Meanwhile, the rest of us are trying out the PC as encouraged by our managers, so you sit down with at least three 5.5 inch diskettes. The first is DOS; insert it in drive A and turn the PC on. The machine would boot, and I don't recall it taking too long (long boots were still in the future). Once you get the A: prompt, take out the DOS disk and insert your Multimate disc, it being the first PC word processor of any note. So, enter MM or something at the A: prompt and it loads. It was green screen, no graphics, and so you created a document, a blank space to type in. When you wanted to save your work, insert a blank floppy disk in drive B: and save it there…as long as you had remembered to format it using DOS before hand. When you are done, take the third disk with you with your work on it, and leave the other disks for the next user.
Given all this, the PC did not really get a lot of users, but my use of a PC was about increase dramatically.
Friday, September 11, 2009
Memories of IT - could computing be fun?
The time periods covered in the previous posts overlap in some cases, so the PC did not just appear in a poof of smoke where I was working, totally unexpected. Lets pause and talk about computing for fun.
I am guessing the first CRT most people of a certain age used was on a video arcade game. Before that, there was pinball and other physical games like baseball (machine pitched a ball and you hit it with a bat in the same way as pinball flippers.) I played these games in many places as a youngster. A bowling alley on a Lake Huron beach comes to mind, and a few trips to the UK where I saw games where you dropped a coin on top of a whole lot of other coins in the hope it would be the one that tips that whole pile of coins into a slot that delivered them to you; my first exposure to gambling, I suppose; And there was skee-ball, trying to win coupons to cash in for cheap toys/trinkets. ( I mentioned earlier about playing Adventure on a teletype at university, but was really only available to students of the time.)
Then the first CRT-based game(s) appear. Was it Pong? Wikipedia would tell us, I guess. What I remember from the 80's was the arcade in the mall next to the office where I first worked, and it had about 20 machines lined up. Here is where I first learned that my eye-hand coordination skills were average or worse. All these games were based around scoring a level of points to get free games (taken from pinball I suppose) or move to the next level. I could get a free game or two, but would crash and burn not long after that point. Some of my-coworkers could play a game for hours on one quarter. They also set up tournaments for co-workers, which I did not enter.
The main game I recall of this period was the first Star Wars game. It was a first-person flyer-shooter, you were Luke in your fighter attacking the Deathstar; you started by battling Imperial fighters, then to the surface to get past tower cannons, and if you survived to that point, you flew into the trench to shoot the bomb down the hole while Darth Vader tried to shoot you down.
If you succeeded, you would start all over again at an increased difficulty level. I recall I managed to get through the first level and into the next, but never farther. Then a guy I worked with would step up and go thru 3 or 4 or 5 levels, and might just walk away before losing, because lunch hour was over. I felt SO inadequate as a game-playing male.
(This reminds me that at this point, really eccentric characters were still something you could be working with --- at the company, they were programming whizzes or knew stuff nobody else knew; so long hair or dread-locks was OK, plus guys in weird suits with fedoras, and more, and they were all great game players; but they all moved on at some point, maybe to develop games.)
Any way, the graphics on the game were neon lines on a black background., simple but effective for a game set in space. The soundtrack was the familiar movie score, with clips of things like Obi-Wan saying "Luke, use the force!". It was fun, I played it a lot, but not once did I walk away because my lunch was over...
I am guessing the first CRT most people of a certain age used was on a video arcade game. Before that, there was pinball and other physical games like baseball (machine pitched a ball and you hit it with a bat in the same way as pinball flippers.) I played these games in many places as a youngster. A bowling alley on a Lake Huron beach comes to mind, and a few trips to the UK where I saw games where you dropped a coin on top of a whole lot of other coins in the hope it would be the one that tips that whole pile of coins into a slot that delivered them to you; my first exposure to gambling, I suppose; And there was skee-ball, trying to win coupons to cash in for cheap toys/trinkets. ( I mentioned earlier about playing Adventure on a teletype at university, but was really only available to students of the time.)
Then the first CRT-based game(s) appear. Was it Pong? Wikipedia would tell us, I guess. What I remember from the 80's was the arcade in the mall next to the office where I first worked, and it had about 20 machines lined up. Here is where I first learned that my eye-hand coordination skills were average or worse. All these games were based around scoring a level of points to get free games (taken from pinball I suppose) or move to the next level. I could get a free game or two, but would crash and burn not long after that point. Some of my-coworkers could play a game for hours on one quarter. They also set up tournaments for co-workers, which I did not enter.
The main game I recall of this period was the first Star Wars game. It was a first-person flyer-shooter, you were Luke in your fighter attacking the Deathstar; you started by battling Imperial fighters, then to the surface to get past tower cannons, and if you survived to that point, you flew into the trench to shoot the bomb down the hole while Darth Vader tried to shoot you down.
If you succeeded, you would start all over again at an increased difficulty level. I recall I managed to get through the first level and into the next, but never farther. Then a guy I worked with would step up and go thru 3 or 4 or 5 levels, and might just walk away before losing, because lunch hour was over. I felt SO inadequate as a game-playing male.
(This reminds me that at this point, really eccentric characters were still something you could be working with --- at the company, they were programming whizzes or knew stuff nobody else knew; so long hair or dread-locks was OK, plus guys in weird suits with fedoras, and more, and they were all great game players; but they all moved on at some point, maybe to develop games.)
Any way, the graphics on the game were neon lines on a black background., simple but effective for a game set in space. The soundtrack was the familiar movie score, with clips of things like Obi-Wan saying "Luke, use the force!". It was fun, I played it a lot, but not once did I walk away because my lunch was over...
Thursday, September 10, 2009
Memories of IT - early 80's - my own terminal, plus email and laser printers
So, I and several other programmers are assigned full-time to the development project. To be productive, management figured out we needed our own dedicated terminals, so we got them, and so did everyone else in the department over time.
A major long-term impact of this was that now we could move from semi-open floor space, where terminals could be shared, to full-on cubicle farms, and that's what happened. Its funny now, because lots of offices are trying to get back to open space, and being trapped in a cubicle is treated as torture, but we were all thrilled when we each got our own 3 and half walls. I think this has carried over into my choices in housing; open-concept and high-ceilings means wasted space. I want walls, doors, and each floor of my house to cover all the available space.
What else was going on about this time? We got internal, mainframe-based email. Up till then, we were still using triplicate memo forms to hand-write messages and send them by inter-office snail mail; can't say I missed that very much, but email was charged for internally for its use of external mainframe cycles, so some departments refused to use it because of that cost, and it usually turned out to my users; but the email worked well, just still text on a green screen and only within the company.
Around this time the company bought its first laser printer for the mainframe, producing excellent quality printing on standard letter and legal paper. What you would do is insert printer commands in your code to produce reports that looked good. We also started typing memos and documents in TSO PDS members, and you would add printer codes that specified font, bold/italics, spacing and more. I think this when my typing started to get faster because of constant use, although I have still never learned how to type like a typist would. (They didn't teach typing to boys in high-school back in the 70's, that was for girls, who also learned shorthand, so they could go right out there and be a secretary! I have to think shorthand really has to be a lost skill by now.)
But even with mainframe email and laser printers to dazzle us, lurking out there was that next great paradigm-shift: the IBM PC.
A major long-term impact of this was that now we could move from semi-open floor space, where terminals could be shared, to full-on cubicle farms, and that's what happened. Its funny now, because lots of offices are trying to get back to open space, and being trapped in a cubicle is treated as torture, but we were all thrilled when we each got our own 3 and half walls. I think this has carried over into my choices in housing; open-concept and high-ceilings means wasted space. I want walls, doors, and each floor of my house to cover all the available space.
What else was going on about this time? We got internal, mainframe-based email. Up till then, we were still using triplicate memo forms to hand-write messages and send them by inter-office snail mail; can't say I missed that very much, but email was charged for internally for its use of external mainframe cycles, so some departments refused to use it because of that cost, and it usually turned out to my users; but the email worked well, just still text on a green screen and only within the company.
Around this time the company bought its first laser printer for the mainframe, producing excellent quality printing on standard letter and legal paper. What you would do is insert printer commands in your code to produce reports that looked good. We also started typing memos and documents in TSO PDS members, and you would add printer codes that specified font, bold/italics, spacing and more. I think this when my typing started to get faster because of constant use, although I have still never learned how to type like a typist would. (They didn't teach typing to boys in high-school back in the 70's, that was for girls, who also learned shorthand, so they could go right out there and be a secretary! I have to think shorthand really has to be a lost skill by now.)
But even with mainframe email and laser printers to dazzle us, lurking out there was that next great paradigm-shift: the IBM PC.
Tuesday, September 08, 2009
Memories of IT - A New In-House Development Project
So, a couple of years into being a Programmer-Analyst... it's still the early 80's, back when jobs had numbers after them, so you would start as a PA 1, progress to PA 2, and so on. Progression also meant raises along with annual increases. I would say this was the period of my career, unique to the time, where my salary grew the fastest. No one had invented bonuses based on company success, you made what you made without concern for company profits, while realizing that low or no profit was not good for job security.
So, a couple of years in, the Corporate Systems department gets a new development project! This is full in-house development, PL/1, IMS DB/DC. The company had been using a system similar to the mortgage system I have described, but for securities: stocks, bonds, money markets, etc. I was not in on the process that led to the decision, still being a junior programmer busy on current projects, but looking back now it must have been a reaction to the realization that every-other-night batch processing was not going to be good enough for stocks and bonds trading. So, this was going to be an online system, where the trades on the markets would be captured right after they occurred. It was not a trading system itself, nor was it connected to one, so the traders were going to record what they did in this new securities administration and control system (more on how that worked out, later).
As I mentioned earlier, the core Individual Insurance Systems were already online using this technology, but it would be the first such system in a Corporate area. Our senior programmer/designer/architect took on the challenge of building a trial online system first, to show it could be done in Corporate Systems, It was an easy-to-develop structure he came up with.
Most online systems have one program for each screen used in the system that handles both out put to the screen, and receiving input from the user. I saw this structure as awkward, as it could be tough to discern which part of a program was being used at any one time. Our architect devised a master control program that would, for example, discern what screen had been just used by the user and pass its input to a program built to process input from that screen. It would do all the editing and, if there were input errors, it would pass that information to a program built to send data and messages to that screen, which would do just that. The user has the response and does what they need to do, hit enter and the whole process starts again. Once the input program is OK with the data its has received, it will then do one of many possible things defined for it; for example, the user may have indicated they want to navigate to another screen, so the input program would pass control (and any needed data) to the output program for that other screen, it does what it does and sends data out to the user, etc. etc.
Just want to remind the reader that this is still a mainframe, green screen system, so next time I will recall how we actually built it, and the good and bad things that happened.
So, a couple of years in, the Corporate Systems department gets a new development project! This is full in-house development, PL/1, IMS DB/DC. The company had been using a system similar to the mortgage system I have described, but for securities: stocks, bonds, money markets, etc. I was not in on the process that led to the decision, still being a junior programmer busy on current projects, but looking back now it must have been a reaction to the realization that every-other-night batch processing was not going to be good enough for stocks and bonds trading. So, this was going to be an online system, where the trades on the markets would be captured right after they occurred. It was not a trading system itself, nor was it connected to one, so the traders were going to record what they did in this new securities administration and control system (more on how that worked out, later).
As I mentioned earlier, the core Individual Insurance Systems were already online using this technology, but it would be the first such system in a Corporate area. Our senior programmer/designer/architect took on the challenge of building a trial online system first, to show it could be done in Corporate Systems, It was an easy-to-develop structure he came up with.
Most online systems have one program for each screen used in the system that handles both out put to the screen, and receiving input from the user. I saw this structure as awkward, as it could be tough to discern which part of a program was being used at any one time. Our architect devised a master control program that would, for example, discern what screen had been just used by the user and pass its input to a program built to process input from that screen. It would do all the editing and, if there were input errors, it would pass that information to a program built to send data and messages to that screen, which would do just that. The user has the response and does what they need to do, hit enter and the whole process starts again. Once the input program is OK with the data its has received, it will then do one of many possible things defined for it; for example, the user may have indicated they want to navigate to another screen, so the input program would pass control (and any needed data) to the output program for that other screen, it does what it does and sends data out to the user, etc. etc.
Just want to remind the reader that this is still a mainframe, green screen system, so next time I will recall how we actually built it, and the good and bad things that happened.
Thursday, September 03, 2009
Memories of IT - early 80's - Computing Goes Online
So, I am in a department of 25 people, all working with coding sheets, until one day, a couple of terminals appear. They are put in the middle of the department, so each person has to schedule time to use one. This is when I first used TSO seriously, using both the command line and the menu-based SPF function, I learned what Partitioned Data Sets were, and how to create files online and allocate space. The main reason to use them was that you could extract a program from the Librarian tool, edit it in TSO and then put it back in Librarian; look ma, no punch cards!. This led to the first "religious war" I saw; if you used Librarian in batch mode, it would track all the changes made to the code, providing a history of changes over time. However, if you used TSO, that updated code would be placed back in Librarian like it was a new program, no history recorded. Well, people were aghast that the history was going to be lost, how could you debug a program with knowing that history, etc. etc.
The fact that I don't remember if I cared one way or the other is the first indication that I have almost never "chosen sides" in debates like this. I might express an opinion, or actually be the analyst defining the pros and cons, but once a decision was made, I was never the person who would be whining 6 months later "we should have done it the other way..." You gotta go with what's been decided, otherwise it's time to move on.
In this case, TSO updating won out and Librarian was phased out over a couple of years. The corollary technique to change history was commenting your program code, inserting text at regular intervals to describe what the program was doing; so, it was decided that significant changes be noted as comments too.
What this led to was a need for more terminals. Over time, we got enough to have one for every two people. It sat on a swivel table between desks, so you could move it to use it when you had something to enter; the other person would do other work until their turn with the terminal came up again. This would still be in the early 80’s, just before a big new project that would change how we worked some more...
Next Time: A new development project
The fact that I don't remember if I cared one way or the other is the first indication that I have almost never "chosen sides" in debates like this. I might express an opinion, or actually be the analyst defining the pros and cons, but once a decision was made, I was never the person who would be whining 6 months later "we should have done it the other way..." You gotta go with what's been decided, otherwise it's time to move on.
In this case, TSO updating won out and Librarian was phased out over a couple of years. The corollary technique to change history was commenting your program code, inserting text at regular intervals to describe what the program was doing; so, it was decided that significant changes be noted as comments too.
What this led to was a need for more terminals. Over time, we got enough to have one for every two people. It sat on a swivel table between desks, so you could move it to use it when you had something to enter; the other person would do other work until their turn with the terminal came up again. This would still be in the early 80’s, just before a big new project that would change how we worked some more...
Next Time: A new development project
Wednesday, September 02, 2009
Memories of IT - early 1980s - Starting to work...
So what was my actual first work? Maintenance, making changes here and there in the Mortgage system. Sometimes there would be a need for a new report, so that might be written from scratch, but often it was take an existing report/program, copy it and change it. Less often, I got to create something totally new; I recall an accounting reconciliation function I developed, matching detail mortgage transactions to GL entries; it was big, intricate, and I was quite proud of it. All of this was done under the direction of an experienced programmer, a nice woman whose name I really wish I could remember, because she got me off to a good start, but left the company not too much later.
Looking back, the main maintenance work is where I first started doing more analysis than coding. Figuring out what the system was doing and how to change it to do what new thing was being asked for, that took more time and effort that the actual coding changes.
I was also lucky to start out in area that literally supported more systems than there were people in the department, so I got to work on many applications over time, from Real Estate Management to Shareholder Reporting to IT Chargeback. I contrast this with the company's main individual life insurance system, which was huge and had a whole department just for its care and feeding.
Other things to note about this period, first half of the 80s:
Looking back, the main maintenance work is where I first started doing more analysis than coding. Figuring out what the system was doing and how to change it to do what new thing was being asked for, that took more time and effort that the actual coding changes.
I was also lucky to start out in area that literally supported more systems than there were people in the department, so I got to work on many applications over time, from Real Estate Management to Shareholder Reporting to IT Chargeback. I contrast this with the company's main individual life insurance system, which was huge and had a whole department just for its care and feeding.
Other things to note about this period, first half of the 80s:
- All the systems in use had been developed in-house
- Batch systems were on their way out; the life system I mentioned above was on-line, using IMS DB and DC. This led to the first down/out-sizing I saw in my career; the internal keypunch group was phased out. The current staff were offered positions with an outside company that continued to do the same work for Crown while it was still needed, but with the obvious expectation that it would be needed less and less over time. At some point, the cards themselves were phased out, with the data being entered in files that mimicked the cards, and those files being used as input to batch jobs.
- The technology/tools used by programmers was also changing; more on that next time.
Tuesday, September 01, 2009
Memories of IT - 1980 - My First System
So, about 6 weeks of PL/1 training, coding some pretty big programs (what they actually were/did, I don't remember) and I am ready for some work. The system I start on is for Mortgage administration; the company loaned money to both individuals and businesses, although the individual business was wound down by the mid-80's. This also meant staff mortgages as a benefit, which I and my wife eventually took advantage of. (oh yeah, got married in 1979 too; she was not in and never has been in IT, a good thing in the long run I think).
So, the Mortgage System, MTG for short. It was a batch system, in PL/1 but not with flat files or VSAM. Someone earlier in the decade had written a little DBMS system that this and other systems used. It was hierarchical, so each mortgage was a root record and had children records of various types, like for the payments collected; this was the Master File. Transactions for the system were written on custom input sheets that went to the keypunch group. All the transactions were gathered up and run against the Master File overnight. The input transactions would be sorted by Mortgage Number/ID, and the main batch program would process Master and transactions in Number order. It would skip past Mortgages that had no transactions, and then apply the transactions against Master records that did. It ran every other night, which gave the business time to look at output one day and then code new transactions the next day.
As I look back it now, it was a pretty good system. Since it was all batch, looking at info for a Mortgage meant printouts. To save paper, the system used microfiche. A printout for each mortgage was put on fiche to begin with, and then each time a mortgage was updated, all the updated ones would get a new-printout on a new fiche. The fiche was numbered, and there was one fiche that had an index of which number fiche to find a mortgage printout on. That index was recreated after each batch run, and would point to the new fiche as needed. Once a quarter, when a lot of new fiche had been added, the system would print a new set of fiche, and the process would start again. There were also monthly jobs for reports, and an annual run for more reports and some housekeeping, like purging paid-off mortgages from the master.
I suppose everyone has a soft spot for their first system, like their first car (mine was a 68 Ford XL) or other firsts. The system would not last forever, but that is another post...
Next time: Starting to Work
So, the Mortgage System, MTG for short. It was a batch system, in PL/1 but not with flat files or VSAM. Someone earlier in the decade had written a little DBMS system that this and other systems used. It was hierarchical, so each mortgage was a root record and had children records of various types, like for the payments collected; this was the Master File. Transactions for the system were written on custom input sheets that went to the keypunch group. All the transactions were gathered up and run against the Master File overnight. The input transactions would be sorted by Mortgage Number/ID, and the main batch program would process Master and transactions in Number order. It would skip past Mortgages that had no transactions, and then apply the transactions against Master records that did. It ran every other night, which gave the business time to look at output one day and then code new transactions the next day.
As I look back it now, it was a pretty good system. Since it was all batch, looking at info for a Mortgage meant printouts. To save paper, the system used microfiche. A printout for each mortgage was put on fiche to begin with, and then each time a mortgage was updated, all the updated ones would get a new-printout on a new fiche. The fiche was numbered, and there was one fiche that had an index of which number fiche to find a mortgage printout on. That index was recreated after each batch run, and would point to the new fiche as needed. Once a quarter, when a lot of new fiche had been added, the system would print a new set of fiche, and the process would start again. There were also monthly jobs for reports, and an annual run for more reports and some housekeeping, like purging paid-off mortgages from the master.
I suppose everyone has a soft spot for their first system, like their first car (mine was a 68 Ford XL) or other firsts. The system would not last forever, but that is another post...
Next time: Starting to Work
Monday, August 31, 2009
Memories of IT - 1980 - Learning to code for real
First day in a real office, wore one of my two jackets and one of my 4 ties, business casual is still decades away. I join the Corporate Systems area within IT (probably called IS at the time), and a team within that area supporting investment systems.
As mentioned before, Crown hired people of all disciplines as programmers, so it starts everyone on a programming course, overseen by one of two IS instructors. I learned that PL/1 code needs to be structured and follow some rules if other people will be able to read and maintain it, so I am quickly cured of some bad habits learned in school. Structured PL/1 means no GO-TO statements, rather one should use procedure calls to sub-routines, with parameters for passing data back and forth. DO statements are another favored construct, both DO x TO y and DO WHILE statements.
Programming technology? Coding sheets, which you gave a group of keypunch people. When ready, you put the deck in a box outside the local operations, who ran it through the reader. The reader and printers are connected by a dedicated line to Crowntec, where the mainframe(s) lived, somewhere in North York.
Given programs of any length, we did use a source management product called Librarian; your card deck would be saved as a Librarian entry/member, and after that you would used Librarian commands to add, delete or replace lines in the entry, again through running punched cards, but just the ones you needed.
Part of running all these decks were cards for JCL, mainly a JOB card with your account and ID, and all the needed PROC statements and such. I think Librarian had JCL in it, but the memory is weak. TSO and partitioned data sets were out there too, but more on that later.
Next time: My First System
As mentioned before, Crown hired people of all disciplines as programmers, so it starts everyone on a programming course, overseen by one of two IS instructors. I learned that PL/1 code needs to be structured and follow some rules if other people will be able to read and maintain it, so I am quickly cured of some bad habits learned in school. Structured PL/1 means no GO-TO statements, rather one should use procedure calls to sub-routines, with parameters for passing data back and forth. DO statements are another favored construct, both DO x TO y and DO WHILE statements.
Programming technology? Coding sheets, which you gave a group of keypunch people. When ready, you put the deck in a box outside the local operations, who ran it through the reader. The reader and printers are connected by a dedicated line to Crowntec, where the mainframe(s) lived, somewhere in North York.
Given programs of any length, we did use a source management product called Librarian; your card deck would be saved as a Librarian entry/member, and after that you would used Librarian commands to add, delete or replace lines in the entry, again through running punched cards, but just the ones you needed.
Part of running all these decks were cards for JCL, mainly a JOB card with your account and ID, and all the needed PROC statements and such. I think Librarian had JCL in it, but the memory is weak. TSO and partitioned data sets were out there too, but more on that later.
Next time: My First System
Friday, August 28, 2009
Memories of IT - 1979 -Finishing University and Getting a Job
Middle of the school year, employers come on-campus to do job interviews. It is still the olden days, so you had to hand-write job applications for each company on a standard form, could have used copy-and-paste....
I recall 3 interviews; I positioned myself as being a guy who wanted to work on real business systems rather than pure techie stuff like operating systems, fairly prescient I think now, but some of the interviewers viewed themselves as techies, so it did not sell well to them. Of course, I had no idea what a "real business system" was. UofT did not have a co-op program, so I had not worked in any IT department; my summer job was not in IT, but I kept it because I could work part-time during the school year as well, and I needed the money year-round.
I think it was an interview with Bell where I hit the techie reaction most.
General Motors was hiring, but their career path for programmers was that you had to start as a computer operator doing shift work. Neither thing appealed to me, but they gave me a second interview, which meant I had to drive out to Oshawa, east of Toronto, where the interview include a tour of Operations. I remember only a whole lot of printers, so feeding them paper would be the main work. GM solved this problem for me by not offering me a job, I think they sensed my reluctance...
One of the remaining interviews was with Crown Life, a middle-size Life & Health company, located on insurance row in mid-town Toronto. The interviewer was more 'touchy-feely' than others, wanted to know more about me as a person, not just as a set of skills. Their next step was to invite you to the head office building for a tour and to write an aptitude test. There was no Operations room to see, as they had already spun off their computer operations to a separate company, and Crown Life was now one of many of its customers. They also gave the aptitude test to non-CSci majors, believing that programming was a skill people with other degrees could master as well. Anyway, I passed the test, got a job offer that actually paid more than others I had seen, although the annual amount would not buy a compact car today. I also liked that they were a PL/1 shop, as I hated COBOL. So, I accepted and started in May 1979...
Next time: Learning to code (for real)
I recall 3 interviews; I positioned myself as being a guy who wanted to work on real business systems rather than pure techie stuff like operating systems, fairly prescient I think now, but some of the interviewers viewed themselves as techies, so it did not sell well to them. Of course, I had no idea what a "real business system" was. UofT did not have a co-op program, so I had not worked in any IT department; my summer job was not in IT, but I kept it because I could work part-time during the school year as well, and I needed the money year-round.
I think it was an interview with Bell where I hit the techie reaction most.
General Motors was hiring, but their career path for programmers was that you had to start as a computer operator doing shift work. Neither thing appealed to me, but they gave me a second interview, which meant I had to drive out to Oshawa, east of Toronto, where the interview include a tour of Operations. I remember only a whole lot of printers, so feeding them paper would be the main work. GM solved this problem for me by not offering me a job, I think they sensed my reluctance...
One of the remaining interviews was with Crown Life, a middle-size Life & Health company, located on insurance row in mid-town Toronto. The interviewer was more 'touchy-feely' than others, wanted to know more about me as a person, not just as a set of skills. Their next step was to invite you to the head office building for a tour and to write an aptitude test. There was no Operations room to see, as they had already spun off their computer operations to a separate company, and Crown Life was now one of many of its customers. They also gave the aptitude test to non-CSci majors, believing that programming was a skill people with other degrees could master as well. Anyway, I passed the test, got a job offer that actually paid more than others I had seen, although the annual amount would not buy a compact car today. I also liked that they were a PL/1 shop, as I hated COBOL. So, I accepted and started in May 1979...
Next time: Learning to code (for real)
Thursday, August 27, 2009
Memories of IT - late 70's - Finishing University
Moving into the later years of university, it is true in any major that the number of people attending the the 3rd and fourth year courses reduces to a core group. So, I spent a lot of time with such a group, and now look back and wish we had Facebook or something, because I wish I had somehow maintained contact with a lot of those people.
In class, I found myself doing well in more commercial topics, like databases, and not so good in more theoretical topics, like Artificial Intelligence. So, it was clear that I was not destined to be a Computer Scientist, emphasis on the 'science'.
In the meantime, being more senior meant access to slightly better technology. One course had us using interactive terminals tied to a PDP computer, but the terminal was tele-type. It printed what you typed, then you typed "enter", off it would go to the PDP somewhere, and it would then comeback and print-out its response. I think I used this to program a B-Tree type of DBMS, which I recall I was quite proud of and got a great mark, but the details have not remained in memory, and the paper print-out disappeared at some point as well.
What this also introduced me to was the first computer game I had seen and played. It was called Adventure, and if you had a user account balance that more than met the need of your course-work, then it was time to play Adventure. It was a text version of what you would recognize as Dungeons and Dragons, or others of that ilk. It typed out that you were standing at the edge of a hole in the ground, you would type 'jump in hole', it would type what you see in the hole, like a key on the ground, you would type "pick-up key" because you would need it later on... turns out I suck at this kind of game, so no DandD play (or WoW) was to be found in my future.
There was also some TSO to be found. If you took on the job of student advisor, you got a TSO account, as long as you sat in a room near the card-reader and helped more junior students with their course-related questions. As was the nature of more senior people, we looked down on junior folks, especially those taking Programming 101 but who were not Comp Sci majors; much sneering accompanied the grudgingly provided answers. I cannot remember using TSO for anything except a text-based golf-game.
Next Time: Getting a job...
In class, I found myself doing well in more commercial topics, like databases, and not so good in more theoretical topics, like Artificial Intelligence. So, it was clear that I was not destined to be a Computer Scientist, emphasis on the 'science'.
In the meantime, being more senior meant access to slightly better technology. One course had us using interactive terminals tied to a PDP computer, but the terminal was tele-type. It printed what you typed, then you typed "enter", off it would go to the PDP somewhere, and it would then comeback and print-out its response. I think I used this to program a B-Tree type of DBMS, which I recall I was quite proud of and got a great mark, but the details have not remained in memory, and the paper print-out disappeared at some point as well.
What this also introduced me to was the first computer game I had seen and played. It was called Adventure, and if you had a user account balance that more than met the need of your course-work, then it was time to play Adventure. It was a text version of what you would recognize as Dungeons and Dragons, or others of that ilk. It typed out that you were standing at the edge of a hole in the ground, you would type 'jump in hole', it would type what you see in the hole, like a key on the ground, you would type "pick-up key" because you would need it later on... turns out I suck at this kind of game, so no DandD play (or WoW) was to be found in my future.
There was also some TSO to be found. If you took on the job of student advisor, you got a TSO account, as long as you sat in a room near the card-reader and helped more junior students with their course-related questions. As was the nature of more senior people, we looked down on junior folks, especially those taking Programming 101 but who were not Comp Sci majors; much sneering accompanied the grudgingly provided answers. I cannot remember using TSO for anything except a text-based golf-game.
Next Time: Getting a job...
Wednesday, August 26, 2009
Memories of IT - 1975 - Starting at University
So, I am off to college...during the day, still living in my parents' basement off campus.
One coding course to start: I like PL/1, dislike COBOL, can't seem to fathom LISP.
Take college level Calculus and Algebra: how could something I was so good at in high-school turn into something I loathed? lucky I didn't choose to be a math major.
Other courses come and go, always looking for the easy course to fill the schedule. A course in Canadian Economics was taught by Mel Watkins, then known as a real left-winger in the NDP. His statement in the first class was that a professor could change anything about a course he wanted to, except the name... so he proceeded to teach communist economics, can't say it has come in handy since, but Mel was just fun to listen to.
Still doing coding language courses, the environment is still primarily punch cards. You create your deck, and then get in line at the back of the room to feed them to a card reader, and then move down the line to a printer which spits out the results. The paper is the old style, wide, white with green lines, holes on the side for feeding the printer. So, you only have so many runs before the assignment is due...
A separate room next door has tables to sit at and work, shoot the breeze with other students. The big issue was that most people smoked then, but a movement was started by the minority to ban smoking in the work room. Looking back, I can see why, the air in the room was blue, but as a smoker in those days, I didn't care.
Speaking of smoke... there were a couple of card-reading machine rooms on the UofT campus, one in the sciences building that I frequented, and another in the main Engineering school building. Well, the latter building suffered a major fire one night, and firemen were clearing the building when they came to card-reader room. With smoke filling the room, students told the firemen, "I just need to run my deck one more time (!)"
One coding course to start: I like PL/1, dislike COBOL, can't seem to fathom LISP.
Take college level Calculus and Algebra: how could something I was so good at in high-school turn into something I loathed? lucky I didn't choose to be a math major.
Other courses come and go, always looking for the easy course to fill the schedule. A course in Canadian Economics was taught by Mel Watkins, then known as a real left-winger in the NDP. His statement in the first class was that a professor could change anything about a course he wanted to, except the name... so he proceeded to teach communist economics, can't say it has come in handy since, but Mel was just fun to listen to.
Still doing coding language courses, the environment is still primarily punch cards. You create your deck, and then get in line at the back of the room to feed them to a card reader, and then move down the line to a printer which spits out the results. The paper is the old style, wide, white with green lines, holes on the side for feeding the printer. So, you only have so many runs before the assignment is due...
A separate room next door has tables to sit at and work, shoot the breeze with other students. The big issue was that most people smoked then, but a movement was started by the minority to ban smoking in the work room. Looking back, I can see why, the air in the room was blue, but as a smoker in those days, I didn't care.
Speaking of smoke... there were a couple of card-reading machine rooms on the UofT campus, one in the sciences building that I frequented, and another in the main Engineering school building. Well, the latter building suffered a major fire one night, and firemen were clearing the building when they came to card-reader room. With smoke filling the room, students told the firemen, "I just need to run my deck one more time (!)"
Tuesday, August 25, 2009
Memories of IT - 1975 - why would you major in Computer Science?
Last year of high-school, Toronto Canada, 1975... can I recall what was driving me?
Other than my "Fortran Programming" course, my focus is on sciences (physics and chemistry, but not biology) and maths (calculus, functions), a little English Lit, and Music, as a drummer.
I am 18 years-old, shoulder-length hair, playing drums in a garage-band, I momentarily scare my parents with the idea of skipping university and trying to be a rock-and-roll star. However, the band never gets out of the garage, I can't sing or write music, and the number of drummers in the local union is large. I was going to be(and eventually would be) the first person in my family to attend university, I had the marks for it, and my analytical bent won out, seeing a degree as something that would my life more successful.
But what would I take? Thoughts of Law were entertained, but then I looked through the course calendar for the University of Toronto, and there was a whole section/discipline on Computer Science. Well, I was the master of Fortran programming, and computers were becoming more known in general as a source of future careers. I elected for a less theoretical program, with a commerce/business minor, as the road to future employment bliss, and just like that, the next 35 years were based on that decision as a teenager. I applied to UofT and other major local schools, was accepted most everywhere, and signed up for U of T for the fall of 1975.
Next Time: Starting University.
Other than my "Fortran Programming" course, my focus is on sciences (physics and chemistry, but not biology) and maths (calculus, functions), a little English Lit, and Music, as a drummer.
I am 18 years-old, shoulder-length hair, playing drums in a garage-band, I momentarily scare my parents with the idea of skipping university and trying to be a rock-and-roll star. However, the band never gets out of the garage, I can't sing or write music, and the number of drummers in the local union is large. I was going to be(and eventually would be) the first person in my family to attend university, I had the marks for it, and my analytical bent won out, seeing a degree as something that would my life more successful.
But what would I take? Thoughts of Law were entertained, but then I looked through the course calendar for the University of Toronto, and there was a whole section/discipline on Computer Science. Well, I was the master of Fortran programming, and computers were becoming more known in general as a source of future careers. I elected for a less theoretical program, with a commerce/business minor, as the road to future employment bliss, and just like that, the next 35 years were based on that decision as a teenager. I applied to UofT and other major local schools, was accepted most everywhere, and signed up for U of T for the fall of 1975.
Next Time: Starting University.
Monday, August 24, 2009
Memories of IT - 1973 - High School Computer Science
Fall 1973, my first introduction to coding sheets and punch-card machines. The class is ostensibly about Fortran programming, but the teacher was barely there. he would write a few keywords on the board, how to define a variable, write an assignment statement, then gave us a problem to solve and program. Most of us looked at each other and said "what the..." but one brilliant guy could figure it out and could be convinced to share some of it with the rest of us.
Once I got a handle on what the teacher was really asking for, I was OK at the basic coding and debugging. We punched cards at the back of the classroom, which were put in a box and taken out of the school to the school board office, where the "mighty computer" lived. Somebody there ran the cards in a batch run, and we got the cards and a print-out back the next day.
If you got the thing working, you got a good mark, and I don't remember any exams, so it was good option course which let you focus on the core math, sciences, english and such that filled up the rest of the day. So, I took it again the next year. I can still recall the classroom and the teacher, but not much at all of what I produced over the two years. I think I learned about GO TOs and DO loops but can't be sure... but it left some kind of impression, because I took it up as my major in university ...
NEXT: Majoring in Computer Science
Once I got a handle on what the teacher was really asking for, I was OK at the basic coding and debugging. We punched cards at the back of the classroom, which were put in a box and taken out of the school to the school board office, where the "mighty computer" lived. Somebody there ran the cards in a batch run, and we got the cards and a print-out back the next day.
If you got the thing working, you got a good mark, and I don't remember any exams, so it was good option course which let you focus on the core math, sciences, english and such that filled up the rest of the day. So, I took it again the next year. I can still recall the classroom and the teacher, but not much at all of what I produced over the two years. I think I learned about GO TOs and DO loops but can't be sure... but it left some kind of impression, because I took it up as my major in university ...
NEXT: Majoring in Computer Science
Saturday, August 22, 2009
Memories of life in IT
I have just been doing the math, and I have been doing IT Projects for 30 years now (I started young...). It made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.
I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.
But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.
Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...
I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.
But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.
Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...
I wrote these posts almost 10 years, and thought I would revisit them, see if remember things any better, and add on as well, so here we go...
Tuesday, July 21, 2009
Complex Adaptive Systems: Why most Information Systems don’t Measure Up.
Complex Adaptive Systems, or Complexity Science, is about a lot more than Information Systems, we human beings being a prime example of such complexity. Wikipedia and other sources provide all the details you want on this topic, but one view of it that has stuck with me over the years is the difference between ‘complicated’ and ‘complex’.
Roughly speaking, a complicated system is what it sounds like, a system that is not simple and not intuitively understandable; however, given time and effort, you could analyze and identify all its parts and pieces and describe the whole system. The key is that it is a fixed system.
In contrast, a complex system cannot be analyzed and described as above because it is changing over time; analyze it last week, and again next week, and you will get two different descriptions. For decades, we have been fairly good at creating complicated information systems, but complex was and is rare, if even considered. Instead, what we have in IT is the Change Request, the Backlog, the up-coming Maintenance Release.
The problem has been our creating of information systems based on the needs of an organization at the time we asked. We were guilty of hard-coding the business process and rules (while probably not recognizing them as such) and delivered that code in working order, to be told that the business wasn’t doing things that way anymore; or worse, the business would keep this to themselves and start creating the first of many ‘workarounds’ needed to get past the system limitations and get things done. In either case, the situation would deteriorate and then the change requests would start coming.
Now, hind-sight is wonderful, and decades of hard, well-intentioned IT work should not be scoffed at; this has been a difficult realization to come to, common in many disciplines where complexity science has tussled with older paradigms; and the realization did come together in pieces over time as parts of the problem were recognized and new technologies & tools were developed to help. The now ubiquitous Database Management System came from realizing that lots of flat or indexed files processed in various batch jobs resulted in lousy information, and certainly weren’t going to work in on-line transactions, and even then we had to work our way through competing designs like hierarchical systems before the relational systems we use today emerged.
However, when it comes to complexity, data needed by a business is comparatively stable; it is how the data is used that changes more. Take a typical business process of handling a loan application; today the big loans go to Fred to process, but next week they go to Anne. That is the kind of change you cannot make to a hard-coded system fast enough to support the business. Beyond that, consider the rules that drive a process, such as loans over $100,000 need to be approved by a VP; and starting next week, it is changing to loans over $75,000.
This kind of complexity has finally led to some changes and new tools to help the business. First out of the block has been Business Process Management tools (BPM), which originated when imaging systems changed offices from moving paper around to moving units of work. More recently, Business Rule Management Systems are being implemented that move the changing of rules from the realm of the programmer to that of the business expert.
Will these tools be enough to move us from complicated, maintenance-heavy systems to truly flexible complex systems? There is no denying it will help; they will certainly solve a lot of old problems, so that we can move on to solving newer, better problems and what more can you ask for.
Tuesday, July 07, 2009
Once a project is started, finish it.
No principle screams from the page to me than this one, yet rarely have I seen it implemented.
I have worked under various managerial styles, but it boils down to two approaches for me, integrated or divided. All enterprises of any size do need to be composed of many organizational units, but that is to divide up the people into manageable groups; it should not divide the enterprise into separate fiefdoms. Just think how many times you have seen or been part of a re-organization, and then think about how many times that has changed the actual work you or anyone else does; the latter adds up to just about nil.
Consider a complete enterprise, with all the usual line and staff functions ; ask anyone in that enterprise how it is structured to do its business and you will probably be shown an org chart. The usual hierarchy of boxes and lines, from CEO down to the base units, is the business graphic that is the oldest and most commonly used. However, why does it have to keep changing? That’s because people are not automons, they need to be grouped in ways that maximize their contribution to the enterprise, while hopefully having job satisfaction and a boss they don’t loathe; and since people come and go, and since people can change over time, any one instance of an organization (as represented by an org chart) will be become sub-optimal as time passes, so re-organization is needed, and it is a good thing if it re-energizes people and re-marshals the enterprise to be its most effective.
The problem is when management believes that the org chart at any one time also represents how the work gets done. Worse yet, they also use the org chart as the basis for changing/improving how the work gets done. This is the ‘divided’ managerial style I mentioned earlier, and it directly affects how the enterprise carries out projects.
At any one time, an enterprise has certain amount of capacity to implement change; the main numbers are how many people there are to do projects, and/or how much money is available to hire outside people to do projects. These numbers are a primary input to that common-place activity of annual budgeting/planning; these numbers are limited/finite, so managers need to decide how to best use them. In the divided managerial style, each major tree below the CEO on the org chart is allocated some portion of those numbers; if you have 10 people available for projects, the number used may be 120 person months. So, Sales is allocated 20 months, Operations gets 40, Finance gets 35, etc. Management may come up with what it believes are equitable/effective means of divvying up the number beyond just dividing it into equal units, but that is a sham; this is further reinforced by the sham idea that if each unit operates and changes successfully in of itself, then the total of all the units’ success will equal the overall success of the enterprise. Does your company have internal charges between departments, often referred to as ‘funny money’? Then your company is divided, because all that funny money means nothing to the bottom line of the enterprise.
A divided approach is a problem when projects are used to improve the business, because projects change the work, not the organization. Take an important and common business activity, order fulfillment. If you trace the work from when a customer first orders a thing or a service, to when its delivery is complete, many (many!) org units will be involved. So, if each unit independently attempts to change/improve that stream of work, they will either overlap with other units or duplicate what other units are doing without knowing it.
The main result for IT is that each org unit will want to use its allocated resources to get its own projects done. So, irrespective of their overall value to the enterprise, a number of projects will get initiated. This will result in overlap or duplication within the systems IT delivers, assuming the systems are delivered. IT management will be faced with conflicting demands on their limited resources, so only some sub-set of the projects will be proceeding while others wait for resources. This leads to projects stopping for a while when they get to a point where they need new types of resources, and then have to start up again when those resources eventually become available.
So, irrespective of the method used to divvy up project resources, the ‘divide’ approach produces an ineffective and wasteful projects environment. The solution to this problem is to move to an integrated managerial approach.
An ‘integrated approach’ recognizes that an enterprise is a team brought together to operate a business, not a collection of independent fiefdoms; a CEO that recognizes and leverages this approach also knows that projects to improve the business belong to the enterprise, and almost always impact multiple organization units. Given this recognition, how an enterprise organizes its resources to carry out projects then will (or should) be tailored to the mix of people involved, just like any other aspect of organization. This could be anything, from ad-hoc teams to a full Project Management Office. Any good structure will do, as long as the enterprise view is maintained.
And that’s all I have to say about that.
Sunday, July 05, 2009
IT Project Cost-Benefit Analysis
Assuming you got through the rough stuff of defining costs and benefits, the analysis should be simple. What you want to know is if the benefits of the project will exceed the costs, and by how much. Since costs and benefits may be spread over long periods of time, Present Values of these amounts are also usually calculated to compare the amounts in “today’s” dollars.
When I did my first Cost-Benefit Analysis for a major project, I had to work with an spreadsheet expert to to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the two dollar values, cost and benefit, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.
Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.
These calculations may be used to determine if a project passes a funding hurdle; its not enough that a project makes money, but it has to make more than investing the equivalent dollars of the project cost in securities or other investments.
After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.
Subscribe to:
Posts (Atom)