Home
Content
As an entry level engineer, I shared a cubical with three experienced engineers, and my assignment was to update the design documentation to reflect the final code for the system. Perhaps my start is the reason for my emphasis on good documentation.
Using the requirements document and the code, I updated the design document. The particular module I was documenting was the display manager module. I happened on a piece of code that appeared strange to me, and so I followed it only to find that it would cause problems elsewhere in the system.
While all three senior engineers in the cubicle I shared, were good, "The Dragon" as he is nicknamed was the most communicable, so I approached him with my problem. It turned out that when I explained the problem to "The Dragon", the problem had been causing them problems for over a month, and they were not able to locate the source of it. The dragon had me transfered into system integration and test, and became my mentor. I was officially an engineer.
Working with the Dragon, my engineering skills improved and so did my reputation within the company. When the project completed, I was an engineer for less than a year, but was assigned to do maintenance on the operating system for a large project. SPUDS was no ordinary operating system. It was a Symbolically Programmed Utility and Debug System (SPUDS) that could function above any operating system except itself. I was impressed that the Ships Operating System didn't know that SPUDS was in control. I won't bore anyone with the technical achievement of SPUDS, but I was and still am impressed with its creators.
On my new project, I found the senior engineers helpful, and appreciated their willingness to share information and answer my questions. The hand that was guiding my career was very helpful on this project as I had the opportunity for some interesting assignments. Following are just a few of my assignments that aided my development as an engineer:
In engineering, especially with real-time embedded applications, projects come to an end. And, so after successful acceptance tests, the project began to disband, and the engineers began interviewing with other projects and companies. I became concerned because I hadn't received any interviews. I asked my manager if it would be OK for me to seek an interview with my previous manager, and he approved.
I expressed my concern about not having anyone ask for me to my previous manager, and he said that he would request me in the next management meeting to place the engineers that are coming available. The afternoon of the meeting, he called me and said that I was too hot, because when he brought up my name, two of the companies strongest managers went at each others throats, but not to worry because I would work for one of them.
At first this seemed like a good thing, but was soon to find out how much damage being wanted can cause. Without going into detail, suffice it to say that the political mess affected my decision to accept an offer from another company.
On my first project at my new company, I was assigned to complete the detailed design and implement a module that required me to use my math background. The designers of the system did an excellent job laying out the logical topology for the system, and the high level design document was easy to understand. This was my third project at my second company, and I was beginning to believe that this is the way system software development was done everywhere.
With the excellent documentation, I was able to finish my assignment ahead of schedule, and was then assigned to help some of the other engineers finish their assignments. Next, I was asked to form a schedule and a team to implement new functionality into the system, and then after implementing the new functionality, was assigned to take over as technical manager for the system as it entered the next phase. This is where I discovered that even with good requirements and excellent high level design documentation, if all engineers do not follow the high level design when doing a detailed design, the whole thing falls apart. I took over the system at the integration and test phase, and they were having problems with the system. Because I took over as technical manager, "they" became "me", and I had to adapt to this new opportunity. I began making frequent trips to the electronic proving grounds where integration and test was going on where I would do some testing, collect all the data pertinent to the problem, and return to my office to analysis the data. As I determined the source of the problem, I would identify the modules causing or being affected by the problem, and form small teams to open the design and code for the modules and make the necessary changes.
Shortly before I left my second company, they were having problems on a large project for a foreign, "friendly" customer and asked me to help out by implementing point-to-point and multi-point protocols to the operating system and the programmable terminals. While developing the drivers and protocols, I learned that the project was not run like a normal project. The requirements for the system were in a constant state of flux, half the technical staff was supplied by the customer and they were constantly changing the code without paying attention to any requirements or design. In short, this project was a formula for disaster, and the software manager was politically bound by upper management who seemed blinded to the problems. The Software Development Manager took pride in successful systems, and without support from upper management, knew the project was doomed and abandoned ship.
When I was "asked" to be the Technical Manager for the project, I assessed the situation, and "respectfully declined" and left also. The best engineer cannot function without support from upper management. Good engineering is a process, and the process must be enforced. To enforce a process takes good management that trusts and listens to the lead engineers.
I didn't enjoy leaving the company. I had helped the manager who left build one of the strongest software development teams I have ever worked with. We set up training programs and assigned mentors to incoming engineers to be the guiding hand to help them through their careers. Sometimes our personal life affects our professional life, and vice versa. As a single parent with three beautiful daughters (two teen-age and one pre-teen), I was concerned about the California environment, so I moved to the mid-west.
My experience prepared me for my next assignment at a company I had dreamed of working for when I was a young child. Following are some of the assignments and experiences that helped me improve my engineering and management skills:
As a Senior Staff Engineer, I reported to the Director of Software Development who had the full support of his upper management up to the president of the division. My assignment was to review all the projects, and make recommendations for implementing a process to improve our products. At first the project managers called me the "directors hit man" behind my back, until they found out that I was really on their team, and then they called "the directors hit man" to my face. I got their support by reviewing their projects and writing my report, but before releasing the report to upper management, I would review it with the responsible manager. Together we would find ways to make immediate corrections to their process, and those that would require funding and support from upper management were reported. After reviewing all the projects, we identified a process that would accommodate all our projects and reduce the cost of implementation.
Most of the projects were in fair shape. One of the critical projects, an ECM system, was headed for disaster. It was using a single processor prototype running under a monolithic monitor and trying to implement it in a distributed system. They had no requirements documented, and the systems engineers were actually standing behind the programmers who were coding on the fly as the systems engineers were giving them requirements verbally.
It was too late to make changes to the hardware without causing severe cost overruns, so we had to work within the constraints dictated by the hardware implementation. Some of the actions I recommended in my report were:
These were harsh recommendations, so I didn't make them on my own. When reviewing this project, I was working in a hostile environment with a NIH complex, and they resented my being there. I made the recommendations under direction from the Director of Software Development, who in turn discussed the situation with upper management.
My immediate contributions after the recommendations were enforced by upper management were:
I received a lot of credit I didn't deserve for implementing the software development process that turned our division into the star division of the company. Without the support of upper management, and the cooperation of the various project managers, the system engineers, everyone, working together, it could not have been done. I will accept credit for being instrumental in implementing the process.
Although I welcomed the opportunity to move back to California, I felt as though I have been thrown to the lions. It was my first experience with a fear driven management style. It was a large project where there were over 20 managers, all of whom were in fear of making a bad decision, and therefore tried to get someone else to make the decision, and if it turned out good, try to assume credit for it. In the short time I stayed, two of their good managers retired early, just to get away.
When a technical locater (A.K.A. head hunter) contacted me to see if I might be interested in moving to another company, I jumped at the opportunity, perhaps a little too fast. I interviewed with the director, received and accepted an offer as project leader (their title for technical manager) on a distributed real-time system. My mistake was that in my blind haste to get out of a chaotic situation, I failed to ask to interview with the manager I would be reporting to, and thinking I would be reporting to the director as I had done in the past.
As much as I tried to get a good software development process in place, I was only successful with the part of the process I was responsible for. My manager would not give me any support, and I failed to convince the chief engineer that we needed a process that at the very least defined the areas of responsibility. By meeting with most of the system engineering groups, I was able to get their commitment to defining and documenting requirements and stabilizing them. There was one system engineer who felt that the area he was defining the requirements for was too complicated, so he had to define how it would be implemented. He made it even more difficult by defining a new "how" almost weekly. I only had a team of twenty software engineers, and the changes were taking my resources. We were able to define requirements that could be implemented and map to whatever this system engineer finally came up with.
As an aside, my experience has proved to me that there is a reason for process. The processes that separates the "what" from the "how" is a good example of the complications that arise when we do not identify what we are building before we try to decide how we are going to build it.
The operating system that was enforced by the manager for this project was an old cyclic operating system, originally written in JOVIAL, and translated into ADA (no requirements or design necessary). I am familiar with the arguments involving cyclic verses event-driven operating systems, but all I wanted to know is will it do the job. The best way to decide is to do a timing / loading analysis. The chief engineer was beginning to wonder about the loading also, and told my manager that a timing / loading analysis should be run. When I was asked to do the analysis, I presented my analysis that I had just completed indicating a failure to my manager, he demanded that I change the results to show that it would succeed or he would have me removed.
Fortunately, I was invited to dinner with a manager I had worked with earlier in my career along with three members of his department. The dinner conversation was technical and challenging, and at the end of the evening, they offered me the opportunity to join them. Although I was the only member of the department without a PhD, I was also the only member with a real-world real-time background. We worked well together by combining theory with practical application. I would rate it as my most enjoyable career opportunity to date. In real-time systems, we are almost always pushing the technology envelope, but at the Research and Technology Center we were unbound by the envelope looking for the direction to take it. I was saddened when the company closed the center.
My research, including the avionics class library and papers, managed to get me the opportunity to work with the missile and aircraft divisions of the company until an opportunity arose in beautiful San Diego.
The Director of Software Development for a large company in San Diego offered me the opportunity to train / mentor the MUMPS programmers in the software development process. My assignment was to introduce structured and object-oriented paradigms, as well as UNIX and C programming. There was concern that because there was no design available for the large MUMPS system, the project might get canceled. I was given the additional assignment to lead a small team to develop a set of tools to reverse engineer the MUMPS code, and generate the design documentation. Although the design documentation project was a success, the effort to enforce a software development process was not supported by upper management, and the director was transfered to the corporate office and replaced.
With the director who hired me gone, and an opportunity presenting itself in systems engineering, I took a new position as a chief engineer. My new responsibilities included running simulations, examining the system for performance bottlenecks, identifying the code responsible for the poor performance, and recommending solutions. I was also responsible for identifying and evaluating new technologies and protocols that could enhance our systems.
Several outside companies heard about the tools we had to analyze code written in MUMPS, and they contacted us to see if we could use the tools to automate the translation of MUMPS to C++. After securing permission to bring the front end of the tools home and port it to Linux, I developed the capability to do an automated translation to C++.
It is much easier to convince a customer that it is better to fix a problem rather than to translate it when you have the capability to translate it.
I had already been working on several failed approaches for over four years, and decided to use the front end of the analysis tools, and a series of filters, and a C++ class library to do a transformation.
After showing the results to my local management, they were enthusiastic and we invited a customer to a presentation of the prototype. Although local management was enthusiastic, corporate management was definitely not. They were even upset that I developed the prototype on my own time. While working on a business plan to start my own company, I was convinced by the owner of a local high tech company that it would be better for me to become a part of his organization than to go through the trials and tribulations of starting my own company.
The move proved interesting, it was my first experience at a small company. I was not only working on my project, but I had the opportunity to learn JAVA and HTML to translate interactive CD applications to web applications. I also began to design systems and applications that could run on multiple platforms, including Linux, Windows NT, and Solaris, etc.
I enjoyed being an engineer at this company, because due to my extensive background, I was given the opportunity to evaluate emerging technologies and determine if they would fit our business.
Unfortunately, the company that was once small grew, and wanted to grow faster. When companies begin to grow out of control, it is a bad sign, so when a recruiter asked me if I would be interested in a position as manager of QA for a well funded company, I agreed to an interview. During the interview, I was asked if I would mind working as a senior QA developer since a manager would spend most of the time at meetings and it might waste my technical capabilities. Weighing the situation, I thought it would be a good opportunity to accept the offer, especially since my salary would be the same for either position.
The company had a good product, and wireless web technology was entering prime time. They decided to port their product to other platforms since the more servers it ran on, the better the business opportunities. Unfortunately, one of the two funding companies did not like competition, and running the product on competing platforms would mean competition. What made matters worse is that one of the platforms the product was being ported to was Linux, the most feared OS of the funding company. Needless to say, even though the company decided to abandon the port to Linux, it was already too late, and the funding was still cut. This led to the over thirty percent of their engineering staff being let go. It seemed to be a last in first out queue, and I was one of the last in. It is unfortunate that the interview process does not present a real picture of a company, and the reality of the company is not known until after a commitment is made to become a part of it. Interviews are two way, and sometimes we find ourselves mis-informed. As a consultant, it is possible to evaluate a situation while doing what one is hired for.
In 2001, the last thing I ever expected is a company that didn't know what the software development process was. The company shall remain nameless, but the formula for disaster is as follows:
| Source | Action |
| Owner / President | Dreamed of moving to SEI level 4 in three years, but expected it to be done by magic |
| Project Manager | Probably an excellent mechanical engineer, but didn't understand the software process |
| Lead Programmer | PhD in Zoology, and read a C++ book. No time for design. The design is in the code. |
| Programmer 1 | Electronics engineer, typical DSP, always improving FFT. Hates thought of software processes. |
| Programmer 2 | Worked at company that had software process and it got in the way of coding. |
| Junior Software Engineer | Was in favor of software development process if it could be implemented. |
| Senior software scientist | An outsider trying implement an application without sufficient requirements or design in a chaotic environment. |