Escape

After entering the funhouse in Aug 2005, I realized the warnings were true: "Do Not Challenge The Programmer" was said to me repeatedly. Here's the story of what I learned at a failing startup in the past year.

It began as an exciting departure from a few years of corporate-job software-guy doldrums. The surroundings were getting less and less exciting, and the folks I was developing with didn't want to excel at their technical expertise; they wanted traffic to go away to/from job and the 3% raise to land on them. Exciting as watching dogs poop.

So I jumped, ready for the consulting world. Except a funny thing happened along the way. I ran into some friends that were in a startup, and wanted to try and make it succeed. They were working in a neat concept and needed more help. The money was right, so I entered as full-time.

Well, one trip through the 400,000+ lines of code (for 40 screens) there gave me food for thought. It was written by someone seemingly out of touch with how client-server software is written for the past 10 years. Custom code for needless tools, buggy designs that poorly mimic things you get out of the box, etc. I took it as a challenge; the gauntlet was thrown! I was going to introduce a world of new modern designs, and turn the codebase into a humming, smaller, porche-engine of strength. Or so I thought.

"Um, who wrote all of this?" I asked. Several conversations starting like this are best condensed as:
"Oh, well GB." [name withheld to protect the crazy]
"GB? THE GB? The GB who is now CEO?"
"Yep."

Now for a company of 17 people this isn't rare. Plenty of software people get a fun idea, write it in their basement for a few years and then try to build a little company around it. However, this person was performing two roles actively: Suited CEO and investment cheerleader, and midnight-frantic programmer guy. I can't say for sure that his CEO skills were lacking - his managerial skills certainly were, but in terms of code, his output was bad. I mean, really bad. "Coding Horror", hair-on-end bad.

Innocently enough, I began to approach isolated concepts in the code and I hoped to remove their terribleness. I have dealth with student-code, monkey-faking-it-code, and i'm-quitting-tomorrow-code, all bad. So I knew exactly what needed to change in many of these cases.

"Dude. Don't challenge GB on his code." I was told.
"Oh comon - if I fix this, we save like 5 hours a month patching and searching for bugs in the whole pile. It's obsiouvsly worth it."
"Worth isn't in the equation. It's not ROA-based. It's emotional. Don't change GB's code. He loves it and thinks everyone else is wrong."
"Well I bet I can show him how this change will improve things." I said confidently.

So I scheduled a meeting and listened as he whiteboarded up why he needed to write a completely new tool. "Because we found Microsoft's one had a bug." This was perhaps true, but when the tool is quite large, one questions that path. I mean, he half-wrote a large tool to mimic an existing one because of one bug. Okay... but when i researched his described "bug" from the vendor and users (MS has a lot of data on this), I found nothing. He seemingly wrote a new tool to replace a one based *not* on a bug, but in it rejecting his bad design.

A red, swirling light blinked on for a second. Whoop! Whoop! Dive! Dive! I had to get to the bottom of how this guy was thinking.

So another meeting, actually several. He began to expain to me his worldview of programming. The dynamics he was trying to achieve. Not a bad goal, but not really part of the business plan, as I saw it. He was in love with his version of how software could be constructed, and quiet/ignorant of how easy it would be to release solid code "the usual way" way faster. He was planning for years of version changes before the prototype was ready and could run for more than a day.

I began a new project. It was a complimentary application as part of the suite they were shipping. It was to replace an existing application and augment its abilities. The business specs were vague, but the technical demands were explicit. It had to accept constant, large changes to the database schema. Why? Because there was no time to do all the analysis.

Think of that last statement. "No time to do the full analysis" - so we're going to write it to accept whatever the customer asks of us. I began to wonder what business we were in. Ideally, you could be in any business until you asked the customer "what do you want?" "Hmm. Ice cream." Okay, here's some software to make ice cream. Sheesh. So no specs, just a large number of iterative prototypes and endless tweaking. Usually this is fast, but when the CEO is out for the day, and nobody else knows for sure when "good" is "good enough", it slows to a crawl. I had to wait until the analyst hat (a small hat) was worn to get feedback.

Well, I stepped up to the challenge, and created a layer of dyanmic data that mirrored the database, but tried to shield the business logic from bombs of changing requirements. I used commonly-available code that worked throughout many companies already. I invented very little, simply reusing what folks found most productive. I was treated like an idiot.

"Why are you doing this like you are? What is the benefit?" He asked me, angrily.
"This is how modern systems are breaking up the impact of changes. The very changes you expressed were going to happen often. It's the beset practice of the industry"
"You're not listening. The market doesn't know our product. Efficiency is not effectiveness. We have a model in place."
"Your model is full of bugs, and has inherent design flaws. I didn't want to create a product that just got to the level of the current applications, but surpassed them."
"Well, now we have to maintain 2 models, and nobody knows how yours works either."
"Not true, I've used code that is fully documented, has a huge base of folks knowledgeable in it. It's from the internet and is already in working systems, not something I made up in my basement."

After a few heated meetings like this, we silently agreed to not talk to one another. Not very good for an analyst and programmer relationship. Occasionally, I'd get emails challenging my releases or designs. "Thanks for the cheerful attitude" I'd write, CC'ing the audience. I wanted to kill him with kindness. Well, actually, I just wanted the programmer to die, the CEO guy could shake hands and type memos as long as he wanted.

Now, fast forward 1 year. Cancel the "different" project because of "lateness", start the technical salvage of the code into other projects, and then present a *new* design for the such a system. (Actually, just more detail of the original design, since it was still good).

Said design is rejected, so 3 engineering members quit. I get a month to unwind and finally (remember this part?) start contracting around town. Whew! What a crazy place.