Anything else just isn't Enterprise enough.

Roger the refactorer

This is the last in my series on strange people I've worked with in the past 30 years. So far we've covered Greg the secretive, Jon the incompetent, and Gary the not-invented-here. Last is Roger the refactorer.

I worked with Roger for about 14 years off an on. Originally he was on a team of about 8, and ended up being the sole support person for the project. The project was a very sophisticated robot used in an automated warehouse. The firmware was first written in Pascal, then later converted to C. Without Roger, the project would have been a failure.

Roger and I were different on many levels. He is left-handed and an artist. I'm certain his brain is wired differently than mine. He would see things that I completely miss. On the other hand, I could see things that he couldn't seem to fathom.

Roger mostly worked by himself for years. It wasn't until 1995 that things started falling apart. The firmware was being refactored to make use of newer hardware. The old 80186 CPU board was becoming obsolete. A team of about 6 was assembled to get the job done. Roger was the lead.

Jon the incompetent was one of the people on the team. He botched his section, while burning about two months. When he moved on to another department, I re-wrote his stuff in about 2 days, and it worked perfectly. Roger then took my stuff, and decided "it wasn't efficient enough".  Note that code space and execution speed on the part I wrote didn't matter. But is wasn't efficient enough for Roger. He refactored my code. He used a lot of bit packing and other bit operations. My code was clean, easy to read, and easy to debug. Roger's code was almost incomprehenisible. Roger spent about one week refactoring my stuff when he should have been working on something that wasn't working. When he was done, I tested his stuff and found lots of bugs. Roger then spent another week getting it working to my satisfaction. What a waste!

Meanwhile, the rest of the team were getting familiar with Roger's code. the problem was, learning his code was a moving target. On any whim Roger would refactor and reorganize his code because he thought of a better way, or a better name for a function or variable. He would reorganize the code constantly, moving functions from one module to another. It drove the whole team nuts.

The project was about a month late, when the president of the company came in for a demo. We scrambled and got the machine to sort of work in manual mode with the jog controls. The president asked how long until the the machine would run in automatic mode. Roger answered, "A couple of weeks."  What was he thinking? The rest of the team guessed that at best it would be three months before we would be done. It turned out to be over 6 months before we delivered the product. Then all the bugs were found on the job site. The customer kicked us out. Roger got another 6 months to get it working for real.

Me? I wanted out of that department as fast as I could get out. I went on to learn Windows NT programming and SQL. Best move I've made.

And if Bored Bystander wants to know, Roger was an Electrical Engineer.
Permalink Fan boy 
June 26th, 2009 7:00am
Ah, two of the most dangerous things in the world:

A software engineer with a screwdriver in his hand.

A hardware engineer with a keyboard.

Sadly, in my career, I've been both.
Permalink SaveTheHubble 
June 26th, 2009 8:09am
++STH, I've had to be both as well.

I wonder how Roger programmed the manual machine.

I've been a PLC programmer.  Basically, you have one computer, the PLC, that continuously polls the I/O on the HW, and handles the switching logic.  The PLC also accepts input operations from another computer, a straight Windows PC even my last case.

The part where you say 'automated', that would be the equivalent of the PC that controls the PLC.  Another guy wrote that in BASIC and he hardly ever talked with us, I can probably count on < 1 hand the number of times he assisted me (don't bother the high-paid "guru"!).  I worked in the HW/PLC dept. It's amazing how even small companies can act so fractured.

So the automated/operations part was quite different, yes.
Permalink lorb 
June 26th, 2009 10:21am
Fan Boy, another great story. I didn't realize that these were part of a series. What were the other ones, besides Jon?

I had a client a few years ago - the owner was also the chief "designer" - who had a highly profitable accounting software product line. The original code worked and worked well but was a hacky kluge.

He knew that the product needed to "grow up" so he spun off a really expensive new development effort to build a replacement product.

His pattern of "management" was pretty much like Roger's. But his refactoring consisted of originating base classes that the rest of the work depended upon, that he insisted on changing and redesigning in mid-course constantly (especially the public interfaces and the inherited behaviors.)

The net upshot is that nothing new in this guy's hands ever worked, and he flogged his FTEs into keeping absurd unpaid overtime hours to labor away on his changes.

They went out of business three or four years ago, in large measure due to not being able to compete with their flagship (original & hacky) product and no new product. (Actually, They sold the customer list to a competitor who trashed the product line.)

This guy was an accountant, btw.

But, as an electrical engineer myself, I will always have a special place in my heart for EEs who can't really code who try.
Permalink Send private email Bored Bystander 
June 26th, 2009 12:23pm
no, a software engineer with a soldering iron is more dangerous.
Permalink LeftWingPharisee 
June 26th, 2009 1:50pm
>> no, a software engineer with a soldering iron is more dangerous.

Off the top of my head, I disagree. Why: someone who doesn't know what they are doing with a soldering iron will just short something out that is probably small.

Yes, it's quite possible that they will damage something big. Usually, though, soldering irons are regarded as serious tools, like Sawzalls, and it doesn't usually occur to a total know-nothing to try using one.

If the SW only guy is trying to "implement" a new design, they will not get anything right and they will get discouraged quickly and give up. IE: if they try to wire an LED and a resistor in series, they will get the resistor wrong, and they will either smoke an inexpensive LED or they will make the resistor so high it doesn't even light. Or they will reverse bias it and it won't work.

The "problem" with code is that it's so malleable, and something completely wrong can *appear* OK and can even work after a fashion. It may require a lot of effort to shake out the deficiencies.

In the meantime, the incompetent coder gets tons of "positive" feedback and can code up a storm of stuff that appears to work but is bad/wrong.

That's the key: software gives you immediate, and often erroneous, positive reinforcement. It's a bit like crack. Hardware doesn't, so much.
Permalink Send private email Bored Bystander 
June 26th, 2009 2:02pm
Thanks for the comments, BB.
The other one was "Gary the not-invented-here".
http://www.crazyontap.com/topic.php?TopicId=49637&Posts=13
Permalink Fan boy 
June 26th, 2009 7:20pm
Can you post the link to "Greg the secretive"?

This is a great anthology of programmer pathologies.
Permalink Send private email Bored Bystander 
June 26th, 2009 7:58pm
BB,

Here is a summary and an extension of the series:
http://www.crazyontap.com/topic.php?TopicId=49725&Posts=0

You can find links to all of the stories there. (There were four).
Permalink Fan boy 
June 26th, 2009 10:13pm
Man, I knew a guy like Roger. Would spend weeks shaving 2µs off some function that was only called once, and when the user pressed a button, not as part of a loop. Here's a tip - UI *activated* stuff doesn't need to be optimized unless there is a problem.

The thing that made me the most mad was that he would REAPPROPRIATE API calls.

Say there was a API call in the driver called DO_X, which was used throughout the code and was part of a published and distributed API. He would think of a new API function he wanted to call DO_X. He would then steal the old call and replace it with completely new, unrelated functionality. No one would know about this and a new driver would be published, the ka-pow, thousands of other programs that worked with the driver worldwide would stop working. By the time it was straightened out, there would be tens of thousands of updates out in the wild. It would take decades to unravel as random people would update to the driver with the problems, and discover new mysterious problems with basically every program in the world. Probably there are still people out there experiencing computer problems who don't realize our drivers are fucking them up.
Permalink Cowboy Coder 
June 27th, 2009 2:56pm
BTW, regarding the EE hate, I've got an EE and I'm sure I'm a better developer than 90% of the people here.

Problems you are encountering have nothing to do with having an EE, has to do with not knowing how to develop software properly, which is a problem with CS, SE and EE people that don't know what they are doing and don't care.
Permalink Cowboy Coder 
June 27th, 2009 4:04pm
My degree is also EE. That's exactly why I crack on EE programmers. I know the breed from the inside-out. Only a few can transcend their obsessive-compulsive ways and become good developers.
Permalink Send private email Bored Bystander 
June 28th, 2009 3:19am
Yeah, other EEs I know are awfully fond of goto and global variables. I'm just saying it's not a hard and fast rule.
Permalink Cowboy Coder 
June 28th, 2009 3:32am
I'm also an EE, but then got a MSCS degree.

Global variables are evil, unless appropriate comments explain the reason for them.
Permalink SaveTheHubble 
June 29th, 2009 3:07pm

This topic is archived. No further replies will be accepted.

Other topics: June, 2009 Other topics: June, 2009 Recent topics Recent topics