University was a bit of a shock. I had a very heavy courseload in first year... more contact hours than I had in my last year of high school... and it fell to me to make sure that all of the prac classes and tutorials I would have to attend were timetabled correctly. I didn't actually know what a 'tutorial' was, and I wasn't much interested in finding out.
The other thing was the maths.
I had never enjoyed maths, but I was good at it. At High School, maths was one of my best subjects, at least in terms of grades. But apparently the university wasn't happy with the standard of maths from incoming students, and we were all subjected to a preliminary test before the first term began to prove our competence. And it was just as well. I scored 12 out of 15 on the test, but all three of the questions I got wrong were all the advanced trigonometry questions. My class at high school had done a different unit when others had done trig, and I hadn't learned any of the advanced stuff. So, on top of the heavy courseload, during first term I had to take extra classes in high school level trigonometry. But it paid off: when I resat the trig test and my marks went from 0 to 100%.
But all the classes were dull. They were teaching Pascal, which I was already bored with, and I didn't learn much in the first semester. My most difficult class was Deductive Logic, administered under the philosophy faculty by a lecturer, Hermann, who was no longer teaching any comp sci because he'd failed most of his students in his subject area in prior years.
Hermann taught us formal reasoning, and it was a lot more difficult than I had expected. They were small classes and I on one occasion fell asleep sitting in the front row, directly in front of him. By then I was starting to perfect the art of only working as hard as I had to, so I got through it with reasonable grades.
I soon found in the following semesters when we took boolean logic in maths and computer science units that I had already covered the material in much greater depth, and those subjects proved easy. A valuable subject, as much as I had disliked it.
But then I pretty much hated everything. I had made a few friends, but I wasn't enjoy my subjects. I wanted to drop out every single semester. Later in first year we were taught about dynamic memory... pointers... and this was something at least new to me. I quite distinctly remember the a lecturer telling us that pointer arithmetic should be done on paper; it was too difficult to do it in one's head... which any commercial programmer working in a native language (at that time, the vast majority) will tell you is patent bullshit. But it was true that pointers were something many students couldn't master. Pointers, I think, are the first big conceptual leap you need to make in order to become a real programmer.
I did not, at that stage, appreciate that most of the people in my classes would never be able to be effective programmers in the real world: even if they could master the technical aspects, the ability to sit down and solve difficult problems all day long is not one that most people are wired for. For my part, I enjoyed the problem solving and I flat out just liked making things, but I felt like I'd already done all of these things before. I wanted to build Skynet, but nobody else was interested in that. It was data structures and algorithms I mostly already knew, employed in the service of meaningless tasks that had already been solved a thousand times. At the end of the day I was promised a semi-lucrative career maintaining ancient software on obscure hardware that would likely be used only by banks, for exciting banking purposes.
I wanted out, but I didn't really know what else to do. I made the Dean's list in first year despite my misery. Second year my courseload was lighter. No more maths, no more deductive logic... but the comp sci classes were less interesting. We did a lot of hardware and operating systems subjects, the only one of which interested me was the brief unit we did in assembly programming. For the third time I found myself studying boolean algebra. I was still bored and I still wanted to drop out.
In third year we got to choose subjects. I knew I didn't want to take anything to do with networks; I was terrified that it would lead me to a career as a system administrator. Sysadmin, I reasoned, was the most miserable job in the world. If the network is running fine, nobody notices. If the network goes down... which they frequently did, and do... even if it's no fault of your own... everybody hates you. Not for me. I wanted to get out of university with as little work as possible, so I tried to sign up for a bunch of easy subjects... but those all had Databases as a prerequisite. I signed on for Databases and somehow then found there was no room for the easy subjects. Databases proved to be the second-most useful subject I took, although it was a long way from being my favourite.
I enrolled in COBOL. I wanted to do C++, but, owing to the strange degree I had enrolled in, I didn't have the prerequisite year of C programming. Third year had a lot less contac hours than first, so I went to the C++ lectures anyway. Within two weeks I decided that I had to find a way out of COBOL and into C++. If I learned COBOL there was the horrible possibility I would one day have to program it in the real world. By the same token, I knew that C++ was a viable language. COBOL was for retirees; C++ was for powerful young men. Besides: at that time the only language I was any good with was Pascal, and I knew that there were no careers in that.
I had to get into C++. There was nothing for it but to try it on, and see what I could get away with... but in the end it was no difficulty. The professor had seen me in his lectures and he just signed me into his subject, without even asking if I had the prerequisites. I dropped COBOL as quickly as I could.
This was the single best thing I ever did in my five years at University.
I liked C++. I had a bit to learn, but I was able to pick up most of it out of the book. I knew it would be valuable and I paid attention and that, more than anything, is the basis of my career in software. Naked C++.
The other big challenge of third year was the Software Engineering team project. I wound up on a team with one friend and four strangers. The project itself was dead boring... an inventory management database app... but we divvied up the work and I buried my head in my area, which was the User Interface. I took on board my task and decided to let everybody else get on with their own. This was a bad idea.
For all the time we spent in documentation, we really had no plan for how to integrate all of the pieces, and ground zero for this was my UI. When the time came, and I saw how inconsistent and flat-out terrible my teammates' work was, I had to get up and leave the lab. I wanted to punch someone. Did they have no pride int heir work? What the hell was I going to do with that mess? The team lead had flown off to China to look for a wife. The programmers who'd made the mess had no idea that they'd done anything wrong. That left me and the 'chief coder', Adrian, whose job it had been to oversee everybody else's work and make sure it would all integrate. I'd done my bit; I decided that it was on him.
This was very selfish of me, but I had big projects due in other subjects that the rest of the team did not. I went off to work on those and I left Adrian to it. Luckily, he rose to the occasion. Adrian worked long hours, day and night, and he got it done. He made it all work and I think our project scored better than anybody else's. I felt bad about having left Adrian to all the work and resolved to never do that again... and karma has since paid me back many times over.
I didn't make the Dean's list in third year, but I didn't go to many classes, either. All the same, I completed my degree with good enough marks that they offered me an honours year, which I accepted... and then deferred. I couldn't handle another year on that campus, with those subjects. Computer Science? What does that even mean? We don't say 'physics science' or 'chemistry science' or 'mathematics science'. A computer is a device, it's not a branch of science.
And what exactly had been scientific about my degree, really? What sort of research did we do, what new discoveries were we making? I had taken classes in other science disciplines, and even the 'soft' sciences were more research-oriented than CS. What I'd learned was really a kind of engineering, no matter how my degree was named. Since leaving I have never once had the word 'scientist' in my job title (although I would, for a time, hold the title of Advanced Researcher).
Did I want to be an engineer? Did I want to go and work for a bank? No, I decided.
I wanted to build killer robots.
Showing posts with label databases. Show all posts
Showing posts with label databases. Show all posts
Friday, 22 July 2011
Thursday, 28 April 2011
Fear and Circuses
The acquisition went ahead and the owner of our company took his payout. He remained a part of the organization, but I think that basically meant that he continued to draw a salary and occupy the most comfortable corner office--a process that had really begun about the time that Bashir was hired.
The man who had mastermind the acquisition by our new corporate overlords, Lester Gould, was technically in charge of our group, but since he was located off site at our new head office this really mean was that Bashir, who served as the primary interface between our group and the parent company, was in now large and in charge.
While our network was refitted to make us a part of the larger company, we had some downtime and all of our ongoing work came to a stop. "Read the manuals," we were told. "You'll be back online in two or three days." Still smarting from nearly being sacked, I decided that this was the opportunity I had been looking for to show how much I really did bring to the table.
When I was first hired on by the company my skills as a database programmer were a key selling point. Our product was built on a flat file database and, as is usually the case, a decade later it had become apparent that this wasn't going to serve our needs very well. Customers wanted multiple-user access to each project, and that was difficult with a flat file system... and in fact impossible without some kind of client-server architecture. Early in my tenure, at my manager Eric's request, I had drawn up some design documents and some UML pictures for this. After some consideration, Eric had then decided not to include me in the meeting where he presented them to the then-owner of the company and nothing ever came of it. A proper back end was something our customers desperately wanted, but it was a huge job and the company simply didn't trust me, a junior programmer with a bad attitude and a shitty track record, to do it. So they did nothing.
I decided that I would spend the three days of downtime building a prototype. It was hacked together quickly, but I did manage to get it working to the point where I could demonstrate what I still think is a quite compelling picture. I could show data migrating into the database, and an object-oriented middle tier capable of reading that data back. I could then show those middle-tier objects adapted back into our usual data-structures, pushed through the graphics pipeline and displayed on the screen with very similar performance to the old system. It was looking good.
I called Bash and Eric into my office for a demo and ran the prototype side-by-side with the release so that they could compare the results. Then I showed them how easy it was to build out the middle tier objects and how to do the migration. It was rough and I did not have that middle tier running as an external server yet, but it certainly worked. I built the prototype on Access, because I had no access to anything else with the network down, but I made it clear that we'd have to find a real database engine. It wouldn't scale up, but it did the job for a proof of concept. We had already learned the worth of Access with the Development Database, and I actually believed they were listening to me now. Bashir's eyes lit up and he congratulated me on my work. Sincerely, I thought. I was pleased with myself for the first time in a year, and I resolved anew to make the most of this adventure. This lasted for almost an entire week.
Word came down from head office that a part of our application needed to be made to work with an external application, which was code named 'Tarzan'. This, of course, was only partially true, but I had no idea how these games were played at the time. Some engineering heavyweights came down from head office to look at our code, and, Rhaj later admitted to me, they had laughed his face.
In order for our product to become part of Tarzan's workflow, we would have to work with Tarzan's database... although the Heavyweights had not decided which database engine to use. I was not allowed to participate in those meetings, but, when Bashir later reported what had been discussed in those meetings to the rest of us he quite deliberately refused to look at me when he revealed that the Heavyweights had weighed up all of the options... and chosen to use Access.
Let me be clear on that. Access would not scale well enough to be useful for our tiny internal development database, let alone for our actual product... and our product was only a tiny part of Tarzan. The Heavyweight engineers wanted to use it for the entire product. Suddenly I was glad I had been excluded from the meetings.
Bash came to me later in the week with a new task: to create a complete data model for our application. I estimated a week for the task, because our project was huge: in addition to the flat file database we maintained a huge amount of data in other formats including, but not limited to INI files, the registry, various rendering formats, and of course, good old Access. It was, frankly, a disaster, and it was difficult to document because I was always finding new bits of persistent data. At the end of the week, when it wasn't ready, and Bashir was unhappy with me. Apparently he had promised it to the analysts for Tarzan could work out how best to proceed with the integration.
I turned the data model in the following week, and within a couple of days Bashir and Rhaj came to see me--both of them angry.
"We showed this to the Tarzan guys and they're appalled!" said Rhaj. "It's a huge mess!"
"That's right," I said. "It's full of duplicate data, the keys are poorly defined, there's been no attempt to normalize it.."
I could see that none of this meant anything to Rhaj. In reply he spluttered: "So why did you write this garbage?"
"Uh... because Bash asked me to document our data model, and that's what I did. I didn't design it... you did."
Rhaj had no reply to this and they left. I'm quite sure that they went back to the analysts and told them that it was the fault of a junior developer (that bloody Pikeman) and that of course it wasn't the real data model.
That was the last I ever directly heard about the database project, although I did overhear Rhaj and Bashir talking about it in the kitchen. It had been given a codename of its own and a satellite office in another city had been tasked with building the entire back-end for Tarzan. Again. They had already spent two years trying and failed, and now they had been authorized to start over.
The tiny part of the mysterious 'Tarzan' that I had witnessed seemed like a circus, replete with clowns and jugglers and jungle beasts but completely lacking in animal wranglers or a competent ringmaster... and it was 3 years over schedule even before we had started doing our part.
That was about the time that the ringmaster, Lester Gould, decided to put down his whip and quit.
The man who had mastermind the acquisition by our new corporate overlords, Lester Gould, was technically in charge of our group, but since he was located off site at our new head office this really mean was that Bashir, who served as the primary interface between our group and the parent company, was in now large and in charge.
While our network was refitted to make us a part of the larger company, we had some downtime and all of our ongoing work came to a stop. "Read the manuals," we were told. "You'll be back online in two or three days." Still smarting from nearly being sacked, I decided that this was the opportunity I had been looking for to show how much I really did bring to the table.
When I was first hired on by the company my skills as a database programmer were a key selling point. Our product was built on a flat file database and, as is usually the case, a decade later it had become apparent that this wasn't going to serve our needs very well. Customers wanted multiple-user access to each project, and that was difficult with a flat file system... and in fact impossible without some kind of client-server architecture. Early in my tenure, at my manager Eric's request, I had drawn up some design documents and some UML pictures for this. After some consideration, Eric had then decided not to include me in the meeting where he presented them to the then-owner of the company and nothing ever came of it. A proper back end was something our customers desperately wanted, but it was a huge job and the company simply didn't trust me, a junior programmer with a bad attitude and a shitty track record, to do it. So they did nothing.
I decided that I would spend the three days of downtime building a prototype. It was hacked together quickly, but I did manage to get it working to the point where I could demonstrate what I still think is a quite compelling picture. I could show data migrating into the database, and an object-oriented middle tier capable of reading that data back. I could then show those middle-tier objects adapted back into our usual data-structures, pushed through the graphics pipeline and displayed on the screen with very similar performance to the old system. It was looking good.
I called Bash and Eric into my office for a demo and ran the prototype side-by-side with the release so that they could compare the results. Then I showed them how easy it was to build out the middle tier objects and how to do the migration. It was rough and I did not have that middle tier running as an external server yet, but it certainly worked. I built the prototype on Access, because I had no access to anything else with the network down, but I made it clear that we'd have to find a real database engine. It wouldn't scale up, but it did the job for a proof of concept. We had already learned the worth of Access with the Development Database, and I actually believed they were listening to me now. Bashir's eyes lit up and he congratulated me on my work. Sincerely, I thought. I was pleased with myself for the first time in a year, and I resolved anew to make the most of this adventure. This lasted for almost an entire week.
Word came down from head office that a part of our application needed to be made to work with an external application, which was code named 'Tarzan'. This, of course, was only partially true, but I had no idea how these games were played at the time. Some engineering heavyweights came down from head office to look at our code, and, Rhaj later admitted to me, they had laughed his face.
In order for our product to become part of Tarzan's workflow, we would have to work with Tarzan's database... although the Heavyweights had not decided which database engine to use. I was not allowed to participate in those meetings, but, when Bashir later reported what had been discussed in those meetings to the rest of us he quite deliberately refused to look at me when he revealed that the Heavyweights had weighed up all of the options... and chosen to use Access.
Let me be clear on that. Access would not scale well enough to be useful for our tiny internal development database, let alone for our actual product... and our product was only a tiny part of Tarzan. The Heavyweight engineers wanted to use it for the entire product. Suddenly I was glad I had been excluded from the meetings.
Bash came to me later in the week with a new task: to create a complete data model for our application. I estimated a week for the task, because our project was huge: in addition to the flat file database we maintained a huge amount of data in other formats including, but not limited to INI files, the registry, various rendering formats, and of course, good old Access. It was, frankly, a disaster, and it was difficult to document because I was always finding new bits of persistent data. At the end of the week, when it wasn't ready, and Bashir was unhappy with me. Apparently he had promised it to the analysts for Tarzan could work out how best to proceed with the integration.
I turned the data model in the following week, and within a couple of days Bashir and Rhaj came to see me--both of them angry.
"We showed this to the Tarzan guys and they're appalled!" said Rhaj. "It's a huge mess!"
"That's right," I said. "It's full of duplicate data, the keys are poorly defined, there's been no attempt to normalize it.."
I could see that none of this meant anything to Rhaj. In reply he spluttered: "So why did you write this garbage?"
"Uh... because Bash asked me to document our data model, and that's what I did. I didn't design it... you did."
Rhaj had no reply to this and they left. I'm quite sure that they went back to the analysts and told them that it was the fault of a junior developer (that bloody Pikeman) and that of course it wasn't the real data model.
That was the last I ever directly heard about the database project, although I did overhear Rhaj and Bashir talking about it in the kitchen. It had been given a codename of its own and a satellite office in another city had been tasked with building the entire back-end for Tarzan. Again. They had already spent two years trying and failed, and now they had been authorized to start over.
The tiny part of the mysterious 'Tarzan' that I had witnessed seemed like a circus, replete with clowns and jugglers and jungle beasts but completely lacking in animal wranglers or a competent ringmaster... and it was 3 years over schedule even before we had started doing our part.
That was about the time that the ringmaster, Lester Gould, decided to put down his whip and quit.
Labels:
access,
data model,
databases,
middleware,
n-tier,
object oriented,
Tarzan
Monday, 4 April 2011
Bashir's Way
Things didn't go so well once we started to do things Bashir's way. Although his regime was better-organized than the chaos which had preceded it, it quickly became apparent that less was getting done under the new systems than we had seen under the old (in which the owner of the company yelled and screamed and threatened until the work was complete).
There were several reasons for this. Firstly, requiring all developers to keep their working copies of the source code on a single network drive mean that it took more than double the amount of time for us to do anything, just due to disk access.
Secondly, the red tape overhead was huge. In addition to the checkout forms, we had to update a spreadsheet with the work we were doing, we had to track our hours on quickbooks timer, we had to submit an hour-by-hour breakdown every week, and we had to sign in and out of the building every day. Bashir's answer? Add more tape.
Bash and Eric had turned the excel spreadsheet into an access database and then they came and asked me (The database guy) if I would write a front-end for it so that the dev team could use it instead of the excel spreadsheet. "I can, sure," I said, "But it's not going to work on Access."
"Why not, Jared?" asked Bashir, rolling his eyes.
"Access does not support multiple users. If you have fifteen developers on this thing all day it's going to break."
"Fine," said Eric. "I'll get Gavin to do it."
Gavin built it in record time. It took about a week before it blew up, and I heard Eric lamenting to Gavin (whose opposite was directly across the hall from mine) "How were we to know that access didn't support more than one user?"
Bashir's process, as he had explained to us with a great number of drawings and, was the familiar development cycle: Requirements are gathered, features are build, QA tests them, development fixes bugs until is satisfied, software is released. Wash, rinse and repeat.
Despite everything--and there is a lot more, which I will discuss in future posts--development finished its first release on the scheduled day and the product went to QA for testing. Neelam and her single junior tester (a nineteen-year-old kid named Colin) went to work and a week later--the end of their QA cycle--they came back to Bashir with a list of which defects had failed QA. Bash was furious! The release was supposed to go out the next day, how dare we fail to fix some bugs the first time! How dare QA fail to rubberstamp the release?
I helpfully pointed out that Bashir's chart showed a cycle from QA to development prior to release, but his schedule did not allow for this. A corresponding black mark went into my personnel file. It would be a while yet before Bashir threatened to fire me for the first time.
Labels:
access,
databases,
QA,
recalcitrance,
release cycle,
rubberstamp
Subscribe to:
Posts (Atom)