Improving the Development Process – Part 1: Setting the Scene

My primary function here at the transportation appliance factory (TAF) is to ensure the quality of the manufacturing systems. Prior to my arrival, quality had deteriorated to the point that they had suffered some major system outages from problems in the software.

The immediate cause of the last big outage was faulty testing. A developer had performed integration testing using a mix of old and new versions of the system and therefore failed to expose a bug in some of the new code. The root cause analysis wasn’t a pretty exercise, but one of the outcomes was a commitment to early integration and testing.

The system architecture at TAF is a mix of Windows and UNIX, with GUI-based applications written in VA Smalltalk running in both environments talking to headless servers running in the UNIX environment. Of course, that’s not nearly interesting enough. There’s actually two plants running at TAF, each with its own version of the manufacturing system. These versions are almost, but not completely, different with a somewhat different mixture of clients and servers running slightly different versions of code in each.

Generally speaking, this results in having to package four to five different Windows images and a half-dozen UNIX images for each plant. Historically, each plant has been treated as a separate system with a separate release schedule. As you can imagine, this has led to some interesting forks in development.

The final challenge thrown into the mix came from the outside world. The TAF generally doesn’t upgrade software unless absolutely forced to by external circumstances. With the impending withdrawal of support of Windows XP by Microsoft, there was pressure to perform an upgrade to Windows 7. The manufacturing system was currently being built in VA Smalltalk 7.5, which is not certified for use with Windows 7. This meant we had to deal with an upgrade to VA Smalltalk 8.0 along the way.

Advertisements

4 Responses to “Improving the Development Process – Part 1: Setting the Scene”


  1. 1 Joachim 2011-03-29 at 02:08

    Hi Tom,

    thanks for sharing your code and experiences with us. I look forward to reading more from you and learn.

    Joachim

  2. 2 Steve Wessels 2011-03-30 at 07:07

    Tom, good read. I wonder if manufacturing’s reluctance to software upgrades is a learned response from previous software quality problems?

    • 3 koschate 2011-03-30 at 11:53

      It’s all of a piece with the “if it ain’t broke, don’t fix it philosophy,” but it’s a reasonable attitude for the most part. No upgrade comes without cost, in testing and deployment if not direct charges. Along with that comes the risk of introducing unknown interactions with other systems. There has to be a reasonable payback to counter those negatives, be it in improved functionality, fixes to bugs that have workaround costs or mitigation of future risks that might incur greater costs.


  1. 1 New Blogger with Smalltalk topics | Joachims Small World Trackback on 2011-03-29 at 02:02

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: