It is difficult to present the accumulation of knowledge and experience into a resume. Following are some of my experiences that make me unique.
I have successfully managed several large projects. A successful project requires not only a good set of requirements, and a solid high level design, but a team of engineers that perform well together. I cannot know everything, so I learn what the members of my teams know, and use that knowledge to put the right people together. I also ask for input from team members and form groups within the teams to work on selected problems.
I have worked on many real-time systems, including Command and Control, Communications, Elint, Radar, and Electronic Counter Measures. Of all the systems I have designed and implemented, the ECM system I designed for the F-15 was the most challenging.
There were no real-time operating systems off-the-shelf that could provide the performance required, so, I had to design and implement the first distributed, multi-tasking real-time operating system to go on a combat air vehicle.
I have done maintenance programming on several real-time operating systems. In fact, if I had not done maintenance on real-time operating systems, my design for the real-time executive REX135 might not have been as successful. The distinction between a normal operating system and a real-time operating system is probably that real-time operating systems lack the fat. My theme when designing a real-time executive is "lean and mean". It is not for the faint of heart, but once the interface is understood, it is relatively easy for experienced software engineers.
Multitasking support provides the parallelism necessary to run complex real-time application systems efficiently. Real-time operating systems exist that provide multitasking support with response times that are more than sufficient for most applications. However, there are instances where applications have timing constraints that real-time operating systems cannot meet, or a lack of memory space prohibits the use of a complete operating system. In these cases, an alternative is a real-time multitasking executive, a stripped down version of a real-time operating system that would respond faster and have less functionality. To find out more about a real-time executive, follow this link to the early Functional Specification Overview for REX135.
Although real-time systems are designed to run with a real-time executive, the development is done in a friendlier environment. I have done development under UNIX, VMS, OS-32, CMS-2, and even CPM to name just a few. I am currently doing most of my development under LINUX, then porting to Solaris on a SUN, and to Windows NT.
Too much emphasis is put on computer languages. I have used many languages, and found that it is important to use a language correctly, just as with any tool, but it is also important to do a design and have a good implementation plan. I have developed systems in many languages including C, C++, FORTRAN, and many more. Although I have seen systems that almost worked without a design, they were expensive systems to maintain, and were prone to fail at the most critical times. I majored in mathematics, and found the discipline I learned applicable to doing analysis, design and implementation. A computer is simply a logic device, and languages are used to describe the logic steps the computer is to perform. If a system is designed properly, writing the code is mechanical, and any language that will support the detailed design will suffice.
I was once tasked to evaluate C++ for use in real-time systems for a large aerospace company, and not only found it to be a good choice, but designed and implemented an avionics class library that is used on multiple systems. Before developing a class library, I evaluated several commercial class libraries and found that each had some nice classes and methods, but they did not provide the right classes and methods for our application. If C++, or any object oriented language, is chosen, I recommend that a class library specific to the target industry be evolved.
I have used JAVA for developing applications that are platform independent. JAVA is also a good language for its object-oriented support. Although I have used C#, I do not recommend it unless it is never going to run on anything but a windows platoform. I view C# as a failure to hijack JAVA, and do not use it if the project is not a windows only solution.
Some languages (Pascal and Ada) I feel are excellent languages for learning the discipline to write good code (although I have reviewed some poor code in these languages).
It was necessary to write LISP applications for several projects. Although slow, it was very useful in developing a prototype AI application that could query a database for information, processes live information coming in over a digital network, and query an operator for information to help make a decision. Unfortunately, after I did the design and built the prototype, I was needed on another project. The customer did like the prototype, and my company won the contract.
I used AutoCad LISP to write user interfaces, and build a demonstration system for a mission planning / evaluation system.
I found Visual Basic useful for putting together a fast prototype to present to a customer that was Microsoft bound. After winning the contract, I did the implementation using Visual C++. Interestingly enough, the customer for this project has decided to move to a new platform, so I may be re-designing the application with a web based user interface on a platform running Solaris or Linux.
Interpreted languages are good for doing quick tests of small applications, or rapid development for applications that do not have to run real-time.
I have used several interpreters over the years, including BASIC, MUMPS, LISP, and REDR. Most people will have never heard of REDR, since I designed it for a special project that needed a data reduction program, but didn't know what data was wanted for reports. I designed a structured language that used the compiler generated symbol table, and the load map to locate the data and generate reports in the format the user specified using the REDR language. Although it wasn't an extensive language, it could handle normal math functions (sine, cosine, tangent, exponent, etc.) and operators. It turned out that it was not only a good data reduction language, but could be used to debug a system when used with REDE (a remote data extraction application).
I developed the requirements, designed and implemented the REDR interpreter / data reduction application as well as the REDR language.
The first assembler I coded was a macro assembler for the L-3050. It was a somewhat disappointing job, since the design was already done, and I was just programming it. I did get to design and implement the macro capability though. I designed and implemented a table driven macro assembler targeted to the Z-80, but because it was table driven, it could have been used for any assembler that could be described using my format description language. Since I wrote it in 'C', I was able to cross assemble for the Z-80 on a VAX running VMS, and a UNIX platform as well as natively on a Z-80 platform.
In addition to writing several assemblers, I have used many assembly languages, including ULTRA-32, ROLM-1669, Z-8000, Z-80, 8080, 80x86, VFAP, and more.
My first translator was actually a FORTRAN to FORTRAN translator. It is a problem when vendors try to extend languages (FORTRAN, MUMPS, JAVA, etc.) or standard protocols (KERBEROS, PPP, etc.) to try to grab a market share and lock out competition. I avoid the vendor (greed) trap by consciously avoiding extensions, even if it means more work up front. I don't like vendors that pull these nasty pranks, and will avoid them if possible. However, our customer had FORTRAN code that was developed on one vendors FORTRAN IV, and wanted to port the code to another vendors FORTRAN 77. I was asked to develop a translator to do the conversion. I was only able to translate a little over 95%, but marked the remainder for manual intervention. The customer and my management were happy with it. Translators are much easier than transformers. A translator is useful for converting similar languages.
I have written many I/O drivers for many operating systems and hardware platforms, including CP/M running on an 8080 through an Interdata main frame running OS/32. I wrote my first I/O drivers for my personal computer when a personal computer meant something (I built it myself). It used the S-100 bus and ran ZPM (a CPM clone for the Z-80). Drivers were not supplied with hardware, but at least the manufacturers provided the hardware specifications. Included with the specifications were the control and status words for communicating with the hardware.
This experience was necessary since a previous employer wanted to hire me as a part-time consultant to write I/O drivers for their target platform (an AN/UYK-7 running SPUDS). Fortunately my full-time employer at the time, allowed it since there was no conflict of interest. I was able to do the design and code at home, and upload it to the site via modem, then fly to the site on weekends to test and debug the drivers.
For over two years, I did part time consulting by designing, coding and testing I/O drivers for terminals, printers, tape drives, disk controllers, and modems, etc.
On one project, I had to program terminals (firmware) so they could function on a serial bus with multi-point protocol, as well as implement the driver for the operating system (OS-32 clone). Using a data analyzer, I noticed that the protocol output from the DIOS board (a customized board) was not correct. I examined the micro-code for the board and found the error, but when I contacted the company that provided the board, they refused to fix it. To work around the problem, I documented the way the board functioned, and modified my driver on the OS side of the interface, and the protocol layer on the terminal firmware so it would communicate without losing data. Needles to say, I haven't heard much about the company that failed to stand behind their product for a while. I wonder if they are still around.
Diagnostic programs are useful, but their use is limited since they tend to test only one function at a time. Although I write diagnostic applications, we had a problem on a system that I felt sure was a hardware problem, but the diagnostics would not find it. After several weeks of finger pointing between hardware and software, I had enough. I designed a program that would only run if the computer was functioning correctly. It could be loaded anywhere in memory and started. It would then begin to travel through memory causing as many conflicts as possible between the I/O controller and the CPU. After I used it to locate the problem, the program was named "confidence" by the hardware engineer I worked with. Confidence was started each night before we left. If it found a problem, the problem was fixed before the days test began. If it was still running quietly, we had "confidence" that there were no hardware problems and the system test began on time.
I have used various tools to build graphical user interfaces including X, Motif, InterViews, etc. I use TCL/Tk on UNIX, or Visual Basic on Windows to rapidly produce prototypes to use when generating requirements. When the customer has a picture to reference, it is much easier to get the real requirements, and Tcl/Tk or VB make it easy to produce quickly. I have recently used a web browser front end for a user interface for a real-time (embedded) system. For most real-time applications, the user interface does not have to perform at the millisecond level, and a browser can be used to present data or get user input, while the real-time portion runs in real-time.
In addition to using the web technology for interfacing with the user, I have written PHP applications to interface with database engines. More recently, I have written CGI applications in C to build composites of PNG and JPEG graphical images dynamically.
I wrote the JAVA applet to parse the HTML parameters to produce the structure charts in the web flow samples for MUMPS.
If done carefully, interfaces using web technology can be used successfully in embedded systems. I am currently working on a design for a system that must have a fast reaction time needed to send a destruct signal to a missile if anything goes awry while testing. The operator interface is significantly simplified using web technology, but the interface to the missile must be dual redundant and fast. I call my method of design "separation of concerns", and it works well if used by experienced engineers with self discipline.
When I design a system, I examine the requirements (if they are available), and perform a structural decomposition (separation of concerns), to determine the types of functionality required for the design. I then categorize the functionality, and determine the type of technology that will best satisfy the requirement for each.
We have come a long way from the days when I had to take real world lines of bearing and convert it to x, y coordinates and CEP so that they could be displayed on the terminal for a Location Analyst sitting at a RamTek display terminal. With the speed of browsers, the man machine interface speeds are satisfied, and it takes less time and effort to prepare the information for display.
On my web site, most of the pages were created using applications that I developed to generate the pages. It is important to understand the capabilities of technologies, and apply them appropriately. This is a talent that cannot be taught, but must be learned.
System / software design is probably my strongest area. I have worked on several very large systems from requirements through integration and test. I feel that with a good design, coding is as simple as rewriting the "structured English" into code. The bloated systems we see on the PC, are caused by lack of design, but the bright side is that it drove the cost of hard drives down.
I have used both structured analysis and design, and object-oriented analysis and design, and make use of the benefits of both. I prefer structure analysis and design for the high level design, then depending on whether the target language is object-oriented (C++, Objective-C, etc.), or traditional structured languages (C, ADA, etc.) do the detailed design using a dialect of structured English, or object-oriented design. I am familiar with UML, that seems to be a compromise between two differing minds, and use it when required to do so.
Software engineering, including design, is an art, and there are no tools that will substitute for skill and experience.
Over the years, I have had to develop tools to help reverse engineer systems and applications that were built and forgotten. I enjoy designing tools, but feel that if managers realized that programs might be around for a long time, and spend funds up front produce design documentation and funds to update the documentation when changes were made, reverse engineering tools and language conversion tools would be unnecessary and in the long run they would cut expenses and increase profits, but fortunately, when money is concerned, it is always big short term gains that win in politics.
I built my first radio using vacuum tubes when I was about 10. My uncle who ran a radio repair shop, helped me draw the schematic and gave me the parts. The switch from analog to digital was easy since digital is so much simpler, even if it cannot perform some of the functions as well as analog can. I went completely digital for the first time when I built my first computer. I feel that my hobby with electronics has helped me over the years. Knowing how to use assembly language effectively requires some knowledge of how the hardware functions.
For example, I was asked to write an assembly program to replace a memory manager on a ROLM 1669 computer that was written in FORTRAN that was taking over 90% of the CPU cycles. I studied the computer specification as well as the instruction set, and wrote an assembler program that increased system performance by over 500% (less than 10% of cpu cycles were spent in the memory manager and system throughput increased significantly).
Hardware knowledge is also required to write the diagnostics described above under diagnostics.
Design decisions are critical to the success of a system design. Usually when I am designing a system, very little is known about it. There are a few solid requirements, a few "must have" features, a few functions that are just "common sense", but not much else.
If there is not enough information to make a design decision, I do not make a design decision. Instead, I write a place holder explaining what is known about what will eventually be the design, and am honest about the fact that there is not enough information to understand a requirement to generate a design.
I prepare a list of the requirements and data necessary to make a design decision. Presenting a list of information required to the appropriate personnel, often will help expedite the collection of data needed for requirements and design.
Occasionally, a decision must be made before enough data is available to make a good decision. In these cases, I make the best decision possible and document the available data that drove the decision.
Design decisions, like requirements should be flexible enough to be modified if necessary. Our knowledge is constantly growing, and information we have today, may be surpassed tomorrow.
When I designed Web-Flow, there were many designs possible. Some of the design decisions were choices of technology, and application of technology. I considered using PHP as an Apache module, writing a CGI in 'C', generating JAVA code for each module, and generating one HTML file for each module that contained all the information necessary to generate the structure chart and use a single JAVA application that is loaded once.
I decided that writing a single JAVA applet and putting all the required data in a single HTML file for each module was the best design. I was able to reduce the number of files that were generated, and the applet is only loaded once by most browsers. My design does affect my customers since they are required to have a JAVA enabled browser, but most major browsers are JAVA enabled.
I tell people that I have a high intellectual level because I have the ability to recognize intelligence in others. To me, this is knowledge. At an early age, I realized that no matter how long I lived, I would never know everything. Although some people have described me as a knowledge sponge because they say "Bob soaks up knowledge", I feel that I just enjoy learning and communicating with people I can learn from.
My successes are not based on what I myself know, but upon knowing the strengths of the people and making sure that they are doing their best at what they know and enjoy.
At one time in my career, I worked with a manager that had an extremely high intellectual level, and I helped him put together what I consider the strongest team I have ever worked with. It was unfortunate that company politics interfered and he left and the team dispersed.
Being a manager is my most difficult challenge. When I manage people, I must sacrifice my own creativity to try to inspire the creativity of the members of my teams. Fortunately, I have found that by not making the mistake of taking over and doing the implementation myself, but taking the time to encourage and guide people, I end up much better in the long run. I have found that by giving guidance, rather than taking tight control, I have even been able to occasionally take time off without worrying that my projects will be a total disaster when I return.