We've all dealt with marketing people who, in the very depths of their souls, believe that if they promise something to a customer, it will magically happen. Regardless of actual manpower, time or cost. It will work perfectly the first time, and every time, because they promised that it would. It will be cheaper than they expected because, let's face it, how hard could it be to build something, even if it's merely software...?

Hope and Dispair

Aargle interviewed with all of the developers and technical folks in his new department. They all seemed sane, grounded in reality and realistic about what was - and wasn't - doable.

Given that, he dove in head first, and in a few short days, pile-drove himself waist deep and upside down into the steaming pile that was the marketing department. He encountered the company Vice President and a Marketing Drone sitting in a conference room doing design work. Since neither was associated in any way with the development team, he asked one of the other programmers who informed him that the VP and MD had decided that the programmers were just too slow because we were taking around a year to develop new products. He continued: they are going to design a product and have an outside company complete the project.

Aargle thought to himself Uh oh, what did I just get myself into? Fortunately, it turned out that the department he was in consisted of perfectly competent developers and support people, and there was real development to do. The other developer also told him that the MD had previously been part of the programming team, got fired for incompetence and was immediately re-hired as the MD.

But We Designed It To Work Correctly

Fast forward two years and the marketing-development project was declared done, even though it was missing features and simply didn't work right. It ran very slowly. While some of that could be blamed on the simple 1MhZ 8051 processor it used, the device's purpose was simple enough that an 8051 should have tackled the targeted tasks just fine.

Hardware guys usually get it right (because chips can't sort-of or mostly-work; they need to work), but seeing this device in action initially made Aargle wonder. Operations that took an instant on a PC took upwards of 10 seconds to compute on this gizmo. There were also interface issues. Depending on what you needed to do, you might have to press up to 6 keys on the keyboard simultaneously. The keyboard was a standard PC set-up, but with custom key-caps. Have you ever seen a color-blindness test? That's what the key-caps were.

Text would be green on red, red on blue, blue on green, and so on. Consulting with a graphic artist for 5 minutes at the start of the project might have saved that part of the project, but it didn't happen.

Customers != Tech People

Of course, when beasts like this are released, the production nightmares are usually quick to follow. Every time one of these devices shipped to a customer, the production staff had to specify unique settings for the customer, then build the binary code which was then put to an EPROM and that in turn inserted into a socket in the device. Failures became a common problem.

The outside contractors told the production staff that it was probably static (electricity) and outlined steps for them to take. Soon the production people were hooking themselves into grounding straps before handling the EPROM and then making sure the new device was inches from the burner so there was minimized activity involved in getting it from the burner to the device. The software would still fail.

In addition to the problems with the chips, getting updates to the customers was it's own little Circle of Hell. It's simply not reasonable to ask non-technical people to pop and replace chips on circuit boards, but that was the update procedure. Update kits were sent to customers, but that failed far too often.

IT to the Rescue

After months of all this, Aargle was tasked to look into the project to see if there was anything at all that could be done. At the very least, even if the software was awful, could it at least get loaded reliably?

The software and customization went out to a file in hexadecimal. That in turn was sent via com port to the burner. How hard could the process be to screw up? Remember, this was created by a Marketing Drone! In the middle of the "C" program used to perform this task was this:

void main(int argc, char **argv) {

   char response[10]; 
   //... 

   printf( "Do you concur? (y/n)" ); 
   scanf( "%s", response ); 
   if ( strcmp( response, "y" ) != 0 ) {
      main( argc, argv ); 
   }

   // ...
}

The use of the word "concur" was merely awkward, but calling 'main' recursively? Huh?

Finally, he found where they opened the hex file, read block after block from it and just wrote it to the COM port they had open. The C standard library doesn't know from flow control. Is the burner picky about it? Yup. The manual was pretty clear about that.

Using a proper terminal program with hardware flow control, he made the company's first properly produced chip - ever. A few scripts for the comm program later and the whole create/burn/install process was finally working.

Aargle told his boss that this was just the tip of the iceberg, and did he want him to look into fixing it up? The boss told him to take a few days and figure out what he could.

After getting the cross-platform development environment going, he got his first successful build of the existing C code. So far so good, and not even a warning. Wait: warnings were disabled. Let's enable them and see what could be fixed. After a good many minutes of watching warnings scroll off the screen at an unreadable pace, that approach was abandoned.

Among the many warnings were hundreds of functions that returned 'int' but there were no return statements. Maybe the compiler didn't support 'void', but that wasn't it. Maybe they were just lucky and nothing was being done with the return value. Nope. Not that lucky. There were lots of loops and conditions that checked for true/false from these functions that had no explicit return value. The return codes were essentially random numbers. Sadly, this was small potatoes.

In digging through the code, he found that there was a single #include file. But this was still in the '80s and the 64K page-limit needed to be heeded on DOS boxes. Eventually, the compiler couldn't handle their all-encompassing header file. At this point a programmer of even below-average skills would realize that maybe it's time to categorize the constants in the header file and then selectively include the various files with the constants. But this was not done.

Instead, they created two matching include files and essentially divided their source files into two groups and included one header file for one half, and the other header file for the other half. Then deleted constants for one group and different constants for the other group until the compilation would once again fit in memory. This stunt was done yet another time when the number of entries once again got too large. This meant there were 3 header files with overlaps. If you changed a constant in one header, you had to go through the others and make sure you changed the matching entries.

One of the reasons that it was so slow was because all of the financial calculations were being done in double-precision math. Even though all the numeric values were whole numbers and simple integers would have sufficed.

Even simple things were done in the least efficient way. While the function to put a single character to the device's display worked efficiently, the software guys created this to output strings to it:

int print( char *text ) { 
   int i; 
   for ( i=0; i < strlen(text); i++ ) {
        putChar( text[i] ); 
   }
}

On a 1MhZ computer, there's a visible price to pay for re-calculating the length of your output string on each pass of the loop. When the screen clear function was called, you could watch the spaces crawl over the display.

Salvation

At this point Aargle told his boss that the code was irreparable, but that he wouldn't mind re-writing it from scratch. Amazingly, he agreed. It was his first chance to be chief cook and bottle-washer on something like this. The complete re-write, including re-design of the keyboard and manuals, documentation and marketing paraphernalia was done in under 6 months... and the production people got to dispense with the silly wrist-straps. And the customers got ZIF sockets for the update chips. 

Marketing:   0 
Programmers: 1

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!