I work on an application that was developed 15 years ago. The target system was initially some UNIX workstations. About 10 years ago the code was ported to work on the Windows NT platform. This is essentially the same version of software that runs today. When the port was complete, the development team looked to the configuration management team to put together some scripts to automatically build the software releases. This task fell to a CM team member that had a UNIX background. So he felt the only logical choice was to write the build scripts using the Korn shell.Unfortunately the target and development platforms were Windows NT. And somehow he got the customer to purchase a site license for MKS Toolkit. This is a software package which emulates UNIX on Windows machines. It has a full Korn shell. Thus the build scripts were written in the UNIX Korn shell running on Windows NT using the MKS Toolkit. About a week after I started on this project, the CM guy that developed these scripts left the project. So the CM Team turned the scripts over to the development team for maintenance.
Just about all of the development team staff are Windows programmers. Now as programmers we can hack any scripts written in any language. But we do not prefer UNIX scripting languages. The changes to the build script showed this. Whenever something in the build script broke or required modification, the changes were hacked in. The result was a very unruly set of Korn shell scripts that accomplished the builds for releases. Now this is not entirely fault of the development team. The scripts were a bit unstable to start with. They worked as long as the original developer was there to run them and tweak them and work on them as we needed builds. Then things only got worse when this guy left.
A few years ago the team got a lot of Java developers added to it. The plan was to port the system from C++ client server to a Java based web version. This port was a disaster. Most of the Java developers left after the port failed. But a few stuck around. They grew tired with maintenance of the C++ client server code. So they were unleashed on rewriting the build scripts. Being Java developers, they chose Ant as the build of choice. The problem is that they did not entirely uncouple the dependence on the MKS Toolkit. So the current build is a mix of old MKS Toolkit utilities and Ant built in functionality.
The final twist is that we have upgraded the tools used to build the application and connect to the database. As a result, our build scripts need to be updated. All of the Java developers have left the project. And we have assigned a Visual Basic developer to make some of the required modifications to the build script. This developer had already written a couple small VB apps to use in our system. But I think he is trying to avoid this for his build modifications. The team is considering a replacement of the dependence on the MKS Toolkit. If we truly need UNIX functionality, we plan to fall back on the Microsoft Windows Services for UNIX which comes pre-installed on all our development workstations. I surely hope the build scripts do not get more complex as a result of our latest change.
