Home
Content
During our careers, we must make many choices. Following is a list of some of the choices one might face during a career. However, before I get into the list, one choice that affects us more than any other must be mentioned. How to allocate our time.
Falsify a report as ordered by a manager, or risk unemployment
Deliver a system before it is ready or do an incremental release
Use an RTOS that meets most requirements or write an RTOS that meets all requirements
This is a difficult choice, and one that I put off for a vary long time. In my early years, I (wrongly) assumed that people moved into management when they were no longer technically competent. Later in my career, I was forced into a line management position, and found that there is a problem trying to be a good manager, and maintaining technical competence. A good manager relies on his technical staff to give him the information he needs to make an informed decision. A technical person relies on a manager to protect them from the politics.
Unfortunately this choice must be made for each system we architect. There are several advantages to using COTS.
Time and money is saved by not having to code it
It is extensively tested (we are counting on this)
I will think of more later
Some of the disadvantages to COTS are
Not all COTS play well together
Some of the code to integrate COTS in more complex than writing a custom application
Rarely is the full functionality of COTS needed for the size of its footprint
No control over the COTS
COTS or not COTS choices are made on a case by case basis.
These choices are not necessarily disjoint. Both paradigms support Data flow diagrams. Structure charts are useful for doing the high level decomposition (logical decomposition) of the physical system. Once the data flow and logical decomposition are done, a choice can be made as to proceed with a procedural decomposition, or an object decomposition. Both paradigms have there roots in the early programming days of modular programming. Either way will satisfy the goal of "separation of concerns" that removes the complexity.
In the early days of C++, I was assigned to evaluate the language. There were many who claimed that C++ could support real-time systems, and just as many who claimed that it would not be able to handle the throughput of real-time systems. The software director at the Research and Technology Center for the company, knew of my successes with real-time systems, and hired me to evaluate C++ and write my reports for distribution within the company.
Although C++ had been out for a while, the STL was not available, but there were several class libraries available. My view of the STL is that it is an abstraction of an extraction of the collection of class libraries.
The research and technology center has since been closed with the down sizing of the company to increase short term profits, so I do not have access to my papers or numbers, but the essence of my papers is that a company knows its business. The company is better off evolving its own class library that models its business that trying to use a one size fits all library. I then proceeded to design and implement the class library for the company's avionics systems. When the research and technology center was closed, I worked with other software engineers within the company to evolve the class library to aircraft flight control systems, missile systems, mission evaluation systems, route planning systems, and many others.
I take a simple view of open source. There is open source that was developed as open source right from the start, this is true open source. I understand quality software, and have found most open source in this category to be good quality. The second type of open source is failed products. These are products that were not robust enough to compete on the market, so rather than just quit, the companies try to put it out as open source with somewhat ambiguous licensing. Actually not so ambiguous, as I have seen licenses for open source that come down to "It is mine, but you can improve it, and it is mine, and I may take it back if I want to". Most of those that I have seen over the years eventually fade into the woodwork, but still they are usually free, so they get a following that will chant the mantra. To see more on my take of open source, follow this link. The benefit of using the second type of open source is that it is free, today.
Open source is not free. When using open source, you are responsible for how it is used. It is true that the open source community is very good at finding and fixing problems, and they do it quickly, It is good to remember that they have lives too, and can only work on their projects when time allows. You may be able to fix a problem and contribute back to the community and help the maintainer.
The biggest problem with proprietary software is that you have no control over it. When (not if) you discover a bug in the software it is reported to the vendor, and it is up to the vendors discretion as to when or if to fix the bug. Sometimes, when a bug is reported, the vendor will say it is not a bug but a feature.
This is a choice that an employee should never have to make, but it did happen. When faced with this choice, the decision you make will lead to other more difficult choices. There is no good outcome..
This is just a question of selecting the right tool for the job. If the data can be laid out in a series of rows and columns (much like a spread sheet), then a relational database engine might be a good choice. H
If the data is complex with a variety of data where many of the data fields are left empty, then an object oriented (multi-dimensional) data base that supports sparse arrays might be the correct choice.
Another consideration is whether the application is object-oriented. If the data will be processed as objects, then it does make a good argument to store and retrieve the data as objects rather than doing complicated joins.
This choice is easy for me. Never deliver a system with broken functionality.
I have been brought onto projects that were running behind schedule and were in danger of being canceled. After doing an assessment of the system, and determining what was working, and what could be working in a reasonable time frame, met with the customer and my management to tell the honest story. In almost every case, the customer understood the problem, and worked with me to come up with an incremental delivery schedule that would not deliver a complete system on the original deliver date, but would deliver a system with testable functionality for a large portion of the system.
One thing to keep in mind is that the customer is on your side. The customer is reasonable. Keep the customer informed.
Again computer languages are tools. There is no holy grail that one language is better than any other language. The system can be built with any language. But consider that some languages were designed to support different applications. Lisp works well in artificial intelligence applications. I have used AutoCad lisp to build a simulation that involved targeting objects (and blowing them up). FORTRAN was developed for FORmula TRANslations and I found it useful for some numerical analysis applications. ALGOL like languages (ALGOL, JOVIAL, CMS-2, etc) were useful for developing algorithms. I used CMS-2 and JOVIAL for C3I, ELINT, SOS systems. .
For an ECM system I was responsible for, we asked the customer for a waiver to use C to implement the system. Originally, the customer stance was that if it was not coded in assembly language, then it would have to be done in ADA. After several meetings with the customer, they said that if I could code a module of their choice in C and it performed close the the module that was already coded in assembly language, and its foot print did not exceed the assembly module when compiles, that he would allow us to code it in C.
I am happy that the customer chose the module because the module coded in C performed better than the same module coded in assembly language. The compiled C code also was smaller than the module coded in assembly.
It is somewhat humorous looking back on it, as one of my peers asked me what would have happened if I had also coded the assembly module.
It is unfortunate that the system designers rarely get to select the language to use. Most of the time it is dictated by the customer or management.
In the early days of computers, if the system crashed, there was an angry mob in front of the system administrators door (or the computer room). Fortunately, the PC came about with an operating system that crashed so much that we now accept the system crashes.
There are however systems that cannot afford to crash because peoples lives depend on them. For these systems, it is advisable to define the requirements for the system being built, and then evaluate the available RTOSs to determine which ones will meet the requirements.
For most systems, a good match can be found, but occasionally we will find that although some are close, some critical requirements are not met.
I was responsible for a mission critical system that has extreme response time requirements that was distributed across multiple processors. I evaluated all the available real-time operating systems and none of them met our requirements for timing or functionality. Fortunately, I had worked on several operating systems and knew their inner workings.
Something to think about when contemplating an RTOS is that if it doesn't work, the system doesn't work. I used the requirements to design a system that would support our system, and designed it in such a way that it provided system debug support at no extra cost or performance degradation.
The decision to write an operating system must not be made lightly. It should be the most tested piece of code in the system even before integration begins. There are ways of implementing the OS so it can help simplify test and integration.
Many times, a programmer will patch a system to fix a problem, and then add the patch to the source for the next release.
An software engineer may patch the symptom as well to keep the system running. But then, continue to investigate the problem to find what caused the symptom
The correct choice is patch the symptom, fix the problem. Most of the times, a patch simply covers up the problem by removing the symptom rather than finding the real cause of the problem.
Just think, if your doctor simply gave you a drug that covered up your symptom, you would think you were OK, until the problem showed up somewhere else, and the doctor prescribed another drug, and this continued for a time. Pretty soon, you would be somewhat addicted to the drugs, and the real problem would still persist. A good doctor will use the symptom to find the cause, and treat the cause of the problem.
So it is with computer systems. Always find the cause of the problem. Unlike humans, healthy computer systems are well documented, so it is much easier to find the causes of problems and create a good fix to keep the system healthy.