Many moons ago I worked with two brilliant programmers named Steve Langley and Barry Varga.  Steve was our boss at the time with 25 years programming experience and Barry became my partner in a software adventure called 5by5, now Bridgewerx.  One interesting note was that Barry and I became Steves boss when he worked for our company a few years later.

 

We worked for a SCADA company who built RTUs for monitoring electrical substations and sending telemetry to a SCADA application.  An RTU is a firmware device with analog to digital interface cards to measure substation line voltage, current, load, transformer oil coolant temperature, etc., and feeds that information to a SCADA system.  A typical SCADA system usually monitored many substations that collectively forms part of the grid.  A substation may need dozens of RTUs and literally hundreds of different firmware applications running to monitor an electrical grid.  We had a catalog of over 300 firmware apps a customer could choose from.  The company also built custom firmware apps for our customers.

 

Each firmware app had hundreds of configurable properties, with no default values or data masks or min and mix values, etc.  Multiply that by 20 RTUs per substation with 20 apps running, each with at least 100 have to be configured properties means that a bunch of poor guys had to hand enter 40,000 property configuration values in order to make the substation automation work.  A software program was developed to allow configuration of these properties and then upload the config file to the RTUs firmware.  It would take six months to commission a substation based on this approach.  The bitch and stitch from the customers and company was that this was way too long and costly.  Our job was to develop a 2nd gen configurator application that would provide automation for most, if not all, of these properties and therefore reduce the commissioning time from 6 months to 6 weeks.  That was our mission Mr. Phelps.

 

This first generation configurator was a classic example of 2-tier architecture and over-engineering.  Using Delphi, the UI was a table editor, meaning that grid controls exposed the database shema directly to end users.  Tsk Tsk.  However, at the time, considered state of the art.  End users either could think like tables (a whole generation of table thinkers and tinkerers was born during the 90s) or could not think that way and wanted a higher level abstraction.  The over-engineering is that the engineering department decided to make every possible firmware parameter, for every firmware app, configurable, never thinking about size or complexity or the future of substation automation - the very business they are in.

 

Enter our team whose task it was to build a replacement for the old configurator to make the configuration process simple and repeatable.  We were object and component guys then.  So when we did the UML on the problem set, it turned out to be incredibly hierarchical in nature.  An electrical grid contains 1 to many substations, a substation contains 1 to many RTUs, each RTU contains 1 to many firmware applications, each firmware application contains 1 to many configurable properties, and each configurable property had 1 to many attributes.  This is a gross oversimplification, but nonetheless it was just a set of hierarchies.

 

Our approach was to build a drawing tool that allowed the Configurator to drag n drop different RTU types from a toolbox onto a canvas and connect the RTUs to a network.  If you double click on the RTU, a physical picture of the firmware collection was displayed with the name of each application.  Double clicking on an app brought up a configuration wizard that had your typical express and advanced modes.  Express mode gave you some simple options of a known working configuration that you can default to so that the system can be up and running ASAP.  Advanced mode exposed all of the properties, plus their default values that have already been set.

 

It was VB6 days for the UI and our only real option was to use J++ for the business objects layer, being an MS shop plus a real object hierarchy that modeled the real world.  Steve gets code automation.  He developed an Excel spreadsheet that contained all of the attributes for each property for every configurable item for every firmware app.  So if we had a property, we could give it a name, description, default value, data type, min or max values, whether it was required or not plus a bunch of other attributes, but I think you get the idea.  We used Excel to capture the human readable semantics and syntax (a DSL) configuration language for RTU firmware applications.  Steve then wrote a VB6 program that read the Excel spreadsheet and code generated J++ abstract and impl classes and next thing you know we have all of our business objects done.  Every time the spreadsheet would change (which initially was often, then settled out), we would regen the abstract classes, but not the impl classes unless we chose to do so.  Of course the impl classes is were our specific implementation code was.  Now of course we have partial classes in the .NET 2.0 framework which makes it even easier for DSL applications.

 

I wrote the configuration wizards and Barry did a masterful job on the drawing tool in which we used a third party drawing component. So far, so good.

 

However, the Delphi Lead Programmer did not want to switch to MS.  Battle ensues.  I wish I could say we won, but we did not. Our product never made it into production, even though there is nothing wrong with the software and meets the business requirements of both the customers and company by reducing the time and cost to commission a substation with their products.  So what happened?  Just soap opera stuff because we did not have a strong executive team to tell the Delphi programmer that a business decision has already been made and we are phasing (y)our configurator out cause it is too costly to us and our clients.  Instead the Delphi programmer quit and then held the company hostage to hire him back on contract (at a much higher rate) to keep working on the Delphi Configurator.  Oh man, sideways.

 

The Joy of Software was how the three of us worked together building software that resulted in a cool product that also met the business requirements.  Our test customer, from a real power substation in the US, was thrilled.  The why they dont get it goes to (weak) executive management for simply not following through on a business decision that they had already made. 

So Why dont they get it?