FCG is now used on three satellite systems. On one program FCG is being used both for the control and the payload software and almost half of the software is automatically generated. While this is significant, the system is not universally accepted throughout the corporation. Two problems dominate: The system lacks user support and maintenance. Many software designers refuse to work within the confines of a reusable architecture and insist on starting with a clean slate.
Why was FCG successful when much more elaborate earlier prototypes failed? Luck was an important part. The challenge experiment created the necessary visibility and convinced management and engineers of the value of the technology. Without the strong support of advocates from within the product division, insertion of new technology would not have been possible. Input from the user community is important. An internal advocate is ideal. Users that feel in control are very supportive. Interestingly, all support came from aerospace engineers whose jobs are more difficult with FCG. All resistance came from software engineers whose jobs are simplified by the tool.
Documentation is as important as code. Using a single source to generate code as well as documentation and other artifacts ensures consistency and simplifies maintenance. Being able to generate custom database records and documentation was a major selling point.
A critical reason for success is minimizing risk. In the FCG approach it is always possible to revert to the old ways if problems should arise. Several features of the system helped to minimize risk: