Introduction

Software engineers have long told their bosses and clients that they can have software "fast, cheap, or right," as long as they pick any two of those factors. Getting all three? Forget about it!

But United Space Alliance (USA), NASA's main shuttle support contractor, had a mandate to provide software that meets all three criteria. Their experience with Python told them NASA's demands were within reach. Less than a year later, USA is nearing deployment of a Workflow Automation System (WAS) that meets or exceeds all of NASA's specifications.

"Python allows us to tackle the complexity of programs like the WAS without getting bogged down in the language," says Robin Friedrich, USA's Senior Project Engineer. Friedrich conceived of the WAS project in response to a significant gap in the way shuttle mission planning was handling data management. "Historically," Friedrich says, "this data has been communicated using paper and, more recently, data file exchange. But both of these approaches are error-prone. Catching and fixing errors as well as responding to frequent change requests can bog such a system down." Complicating the issue was the challenge of finding money to improve the flight design process in an era of declining budgets for space activities.

"Just in time" provides a solution--and more problems

USA decided they needed a way to "minimize data changes and the resulting rework." The shortest route to that goal would be to shift the design work to the end of the process so that flight characteristics would have a good chance of already being finalized. In other words, as Friedrich says, "We decided we needed to do this data management work 'just in time'."

A just-in-time solution, however, generally puts more stress on both people and systems to get things right the first time because postponing these activities to the end of the process means a loss of scheduling elasticity.

"The obvious answer," according to Friedrich, "was to create a central database repository to help guarantee consistency and to provide historical tracking of data changes." An Oracle database was designed to store the information, but a graphical front end to manage the process of workflow automation was clearly an essential component of an effective solution. "We knew from experience--we do a good bit of Java coding in our group--that using C++ or Java would have added to the problem, not the solution," Friedrich maintains.

Python a mainstay since 1994

Enter Python. "We'd been using Python since 1994," says Friedrich, "when I literally stumbled across Python as I was searching the pre-Web Gopher FTP space for some help with a C++ project we were doing." Being an inveterate systems engineer, Friedrich "just had to investigate it." He was stunned by what he discovered.

"Twenty minutes after my first encounter with Python, I had downloaded it, compiled it, and installed it on my SPARCstation. It actually worked out of the box!"

As if that weren't enough, further investigation revealed that Python has a number of strengths, not the least of which is the fact that "things just work the first time. No other language exhibits that trait like Python," says Friedrich.

He attributes this characteristic to three primary language features:

• Dynamic typing
• Pseudocode-like syntax
• The Python interpreter

The result? "We achieve immediate functioning code so much faster in Python than in any other language that it's staggering," says Friedrich. "Java and C++, for example, have much more baggage you have to understand just to get a functioning piece of software.

"Python also shines when it comes to code maintenance," according to Friedrich. "Without a lot of documentation, it is hard to grasp what is going on in Java and C++ programs and even with a lot of documentation, Perl is just hard to read and maintain." Before adopting Python, Friedrich's team was doing a good bit of Perl scripting and C++ coding. "Python's ease of maintenance is a huge deal for any company that has any significant amount of staff turnover at all," says Friedrich.

The team had already developed a moderately large number of C++ libraries. Because of Python's easy interface to the outside world, USA was able to retain these libraries. "We wrote a grammar-based tool that automatically interfaced all of our C++ libraries," says Friedrich.

Another aspect of Python that Friedrich found eminently significant is its shallow learning curve. "We are always under the gun on software projects, like everyone else," he says. "But for any programmer, picking up Python is a one-week deal because things just behave as you expect them to, so there's less chasing your tail and far more productivity." He contrasts that with C++ and Java, which he says takes a good programmer weeks to grasp and months to become proficient.

Friedrich says that even the non-programming engineers at USA learned to do Python coding quickly. "We wanted to draft the coding energy of the engineering staff, but we didn't want them to have to learn C++. Python made the perfect 4GL programming layer for the existing C++ classes."

One coder and 17,000 lines of code later

The WAS project, which has required somewhat less than a man-year of effort, has been coded by a single Senior Software Engineer, Charlie Fly, who has cranked out some 17,000 source lines of code (SLOC). Python plays the central role, managing data interactions and the task network, as shown in Figure A.

Figure A: Python plays a central role in data interaction.

In the system, user tasks communicate with a Python data server, which in turn connects to an Oracle server via DCOracle. Using Oracle's built-in trigger mechanism to send a message to WAS as data records are updated, the WAS calculates which tasks are now data-ready and notifies the appropriate user.

At the core of the design is the Task object, which stores all information relevant to a single task in the workflow network. The end user can view the network in a PERT-style chart layout (Figure B), where color coding reveals at a glance which tasks are finished, which are in process, and which have not yet been started.

Figure B: PERT-style layout

Two other graphical interface windows allow the user to manage the dependencies among data items in the network (Figure C) and to view and edit individual task details (Figure D).

Figure C: Interface 1

Figure D: Interface 2

All of the code for the UIs was also done in Python, using the popular Tkinter library along with an open source package of supporting modules. Tkinter is included in all standard Python installations.

"USA is pleasantly surprised by how much quality software we can deliver," Friedrich says. "And each time we demonstrate success with Python, we add a few more believers to my growing list!"

About the Author

Dan Shafer is a freelance author and sometime Python coder who hangs out on California's central coast. He is a member of the PythonCard Open Source development team creating a GUI-building framework for Python applications. He makes his living as a writer and a product development consultant. A founder and former editorial director of Builder.com, Shafer has been part of the Web development community almost from its inception.