Programmer's conundrums

In article <200604050313.k353DEvL019892 at mwave.heeltoe.com>, Brad Parker <brad at heeltoe.com> writes: On the other hand, I've worked on the reverse. A huge assembly language program that should have been written in C. (Hi Fred Brooks!) <STORY MODE="verbose"> It was 1986 and I was so fresh out of UDel's EE department with my degree that the chairs were still warm in the classroom from me sitting on them. I got a contract job with the Glasgow facility in DuPont (yes, *the* DuPont of Delaware). Glasgow was their medical instrumentation division and they had bought out Sorvall, a company that makes high-speed centrifuges. I mean really high speed, like 50,000 rpm? (my memory is fuzzy on the exact number, at least 10k). High speed enough that if the rotor got loose from the motor shaft, it would turn you into hamburger. They deliberately failed one of the rotors in a test chamber lined with 6 inch thick oak. The rotor made a 3 inch dent. But I digress.... They hired me as a contractor as squeeze labor to help get this software done that they had been writing for the front panel user interface. It was a 6809 processor with a membrane keypad (newish idea at the time), some LEDs and a 2x40 character backlit LCD display. It communicated to another 6809 processor that ran the motor. (Thank god the UI guy didn't do the motor code or I would be scared.) This project was being poorly managed and it was also being poorly engineered. The UI panel code had somehow ballooned into 100,000 lines of partly commented 6809 assembly language code. It had a floating-point library and was doing complex scientific calculations and had a fairly elaborate menu for programming in various centrifuge tasks. At one point I analyzed a data path and saw a number get converted from integer to fixed-point to floating-point, do some math on it, floating-point to fixed-point and converted back to integer. This was just one example, the whole thing was a rat's nest of gobbeley gook. When I signed on, we were using a cross-compiler on a PDP-11 (I think it was a /34 or a /45 running something with a versioning file system?) and were not using linkable object modules. Instead if you made a change you had to reassemble the entire 100,000 line mess of source files. It took 8 hours to assemble the output file for the test harness. I reworked all the source files to export the entry point symbols and import the symbols called by that source file. Since there were hundreds of source files, this took a while, but was easy to do. Then I could assemble the .asms into .objs and link .objs together to get my final output for the test harness. This cut the edit/compile/test cycle down to about 45 minutes (it still took a long time to link). The target environment was pretty resource rich on the PROM and RAM side, This was not a machine that was starved for resources, but it was being treated as such. During the time I was there, I could have single-handedly rewritten the entire thing in C using a cross-compiler. Instead I was instructed to use assembly language, which I did. Aside assembly language for anything work related. Had I rewritten it, I'm fairly certain that the ROM image would have been smaller and I'm absolutely certain that there would have been fewer bugs. </STORY> At one point, after having repeatedly embarrassed the lame engineer who was coding the UI by fixing his bugs, he accosted me in the hallway and told me (and I quote): "Your job is not to fix bugs. Your job is to do what I tell you to do." Umm...yeah. That pretty much sums up what was wrong with that project :). -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>