I started working with USAFMSA in June 2002.
I was hired as a simple office automation assistant, condemned to
shredding paper and other meaningless jobs – at least for the first month.
Word got around that I had some computer programming experience, and
I was assigned to work under a contractor responsible for maintaining the
TAADS (The Army Authorization Documents System), an old console system
developed in the 1980’s. Needless
to say, this ancient tool worked off a blue console screen, with no mouse,
and obscure commands. The
contractor was working on a new system to work with Windows, named WINTAADS. WINTAADS was an idea conceived by a civilian employee.
At the same time, a project called the Force Management System (FMS)
was also being developed – except contracted out for a hefty price.
No one had seen a working FMS product at this point, so the WINTAADS
project started getting more recognition in the workplace.
The idea was to take the same TAADS data and optimize the routines to
work in Windows using Visual dBase as the development tool.
WINTAADS would be developed by civilian GS employees, for GS
employees, thus not requiring another expensive contract.
I started working on the TDA portion of WINTAADS, called
TDABuilder, under the contractor. Unfortunately,
he was not an experienced programmer, so most of the useful features were
being programmed by the lowly summer hire.
The managers realized this, and let the contractor’s contract
expire. By this time I was back
in school, but returned in winter to make some more progress.
The following summer of 2003, I was the only person working
on TDABuilder. This project had
been halfheartedly going on for years, and was now at version 8, but still
not good enough to replace the old TAADS system.
I was working toward version 9, which would have to be operational
enough to replace the TAADS system. The
initial release of TDABuilder 9.0 contained the essentials to build and
analyze TDAs, as well as a few enhancements to basic features of version 8.
Once version 9 was compiled and installed on the USAFMSA computers,
the old TAADS system was gradually shut down.
It is important to note that even though TDABuilder was new,
enhanced, and functional, it was still not widely accepted by the USAFMSA
documenters. Sure, TAADS was a
homely blue screen, and changes had to be made line-by-line, but to the
documenters who had been working with it for decades, it was a familiar and
stable piece of software. Therefore,
it was essential to the success of TDABuilder that the software continued to
be upgraded so that it could surpass the TAADS functionality, and replace it
with a more efficient and user-friendly operation.
By winter of 2003, USAFMSA was working three systems at the
same time – TAADS, WINTAADS, and WebTAADS.
Each had a completely separate user interface, password, and set of
rules. The eventual fall of
TAADS occurred when the server crashed.
It was decided that the TAADS server would not be resurrected, which
meant that all work would have to be done in WINTAADS and WebTAADS.
So, WebTAADS was setup as the main server, and an interface had to be
developed in WINTAADS to connect to the web server.
Finally, by the end summer of 2004, the final changes were
ready to make TDABuilder a fully functional system for TDA documentation. Documenters
can now download, edit, analyze, and upload their data with ease and
efficiency. TAADS is no longer missed, and now automation at USAFMSA has
become a priority rather than a luxury.
But that’s not the end of the TDABuilder story.
The contracting company that was working on the new FMS system
demonstrated their multi-million dollar product during the summer of 2004.
Finally the real system, the one that would replace WINTAADS and
provide new documentation support to USAFMSA, was revealed.
And it was rejected. The
contractors were sent back to the drawing boards with a copy of TDABuilder
to guide them.
