This has been and looks to be interesting. Clearly too soon to write anything yet.
I can pull a number of lessons from working at Quest. Most are of the kind "things that I will not do again"!.
I turned down their offer the first time around. In part because one of their existing products (Vista) was too similar to what I had done at FileNet. But the guy trying to hire me was persistent, and despite some vague misgivings I accepted their offer.
In the end it became apparent that Quest was a bad fit.
The first project involved feeding print jobs from Windows PCs to a (mostly) existing Unix-based enterprise print management system (from another vendor). After sorting through the requirements, and pointing out the semantic mismatch between Unix and Windows printing (not a small problem), this project faded out. This was a good thing given the rather heavy implementation cost on the Windows side, and the fact that other vendor's print management system has since sunk out of sight.
About this point (a couple of months after I started) the guy who had hired me left.
Helped out with the Vista (a Windows client/Unix server report distribution product). Pointed out the more obvious failings in the implementation to he guy who I later learned have just done a grand re-write (oops) and later became the manager for that group (oops).
Ended up doing a fast port of the Vista server implementation from Unix to NT as a one-man stunt. The final result was buildable on all platforms from common sources. The NT version was a lot more efficient than the version when I was done. Not that this is due to a difference between NT and Unix. Given a bit of time could have made the Unix version as efficient as NT (and likely more robust). Didn't get that time as got pulled off to port another product.
Ported another product (that probably should remain unnamed here) from Unix to NT. This didn't go as well. To successfully do a fast port, the product needs to be fairly stable, so that the base from which the port is started does not change too much during the port. I asked, and they did believe the product stable. It wasn't. As soon as the NT port started to work, I started writing test cases, and started breaking the product. Some of the faults were introduced by the port. I expected this as the port required quite a lot of changes (one reason I was writing test code). What I did not expect was to find serious flaws in the base product with simple tests.
Finished the port, in the sense that the product could be built for any platform from common sources, and it worked as well as the base product (which was not very well). In the end the product needed a major re-write before it could ship, and the work done for the port was abandoned.
MDIS was different. Most interesting was the guy I interviewed with, rather than the company or the product. The company presented an almost classical case of a software house with a broken process. James was heading up the Irvine office of a primarily U.K. company. He had already precluded mistakes I was familiar with: split development and potentially competing groups. In short, a long shot but worth trying.
It was a turn-around, and we *did* get quite a ways forwards. Eventually the company reverted to old habits. James left, and I left shortly afterward.
The above sounds a bit too negative. The company looked like it was going nowhere, but the experience was interesting and I got to work with some good people.
When I joined Upstanding Systems they were about a year old, and had just become profitable. As Upstanding was a small software company (about a dozen people, roughly half writing software), a portion of my time was devoted to direct customer support.
Direct contact with the customers gave some insight into the issues and problems faced by companies with existing mainframe systems. These companies are making increasing use of PC's, Unix-based servers, and local and wide area networks. There is much focus on developing and deploying business-specific client/server and workflow kinds of applications.
Software development was done using Borland C++ for both DOS and Microsoft Windows.
At the time I joined FileNet, they were about to ship their first system to a paying customer (as opposed to a test site). FileNet was a relatively well-financed start-up, having received on the order of 10 million dollars of venture capital. The engineering group at the time was about thirty people, of which more than half were writing software. The FileNet software base eventually became rather large, about two million lines of code, with the attendant programming issues.
The original FileNet system was built on top of a heavily modified version of the original Unix v7. Diskless workstations accessed dedicated file, database, image and print servers over a LAN. Designs were heavily influenced the need to efficiently store and access millions of long-lived images (stored on optical disk), to minimize the load imposed on the servers by the workstations, and to provide workflow interfaces to all major desktop applications.
Software development was done in C for FileNet's Unix-variant. I became familiar with and proficient at using many of the tools available under Unix.
The interesting part of working for Burroughs was the insight it afforded into the workings of a large company. At Burroughs we did the "right" thing in laying out the design of our Programmer's Workbench project in great detail, and undergoing extensive review before beginning development. The project was ultimately upsurped by another group that had instead built a prototype without detailed design. During the course of the project I witnessed the political infighting and resistance to change that seems to often be the bane of large companies.
As the original project was fading away, I applied the familiarity I had gained with PC's (which were new at the time) to writing an emulator for a Burroughs terminal to run on a PC. The product of this essentially bootleg project ended up in widespread use inside Burroughs about a year after I had left, when PC's were deployed within the company (which had merged with Sperry to become Unisys).
Software development as done in Modula-2 and Borland Pascal on the IBM PC.
Western Digital was a smaller company (about $30 million in income a year) at the time. At WD I worked on a number of small projects. As WD was (and is) primarily a hardware company, the work included writing device drivers and diagnostics. This in turn required spending significant time debugging with the engineers that had designed the hardware.
Software development was primarly done in UCSD Pascal on the Western Digital Microengine (an early personal computer).
$Date: 2002-12-22 23:39:08 $ |
home |