The Magical, Erratical, Sometimes Tragical Money Shrinking Machine

It should come as no surprise, given the fiasco I've been documenting on this blog, that my company isn't profitable. We burn through an amazing amount of money per month. Given our bottom line, our only viable option as a business would be to become money launderers. Although, I'm not sure a 10 to 1 exchange rate of dirty to clean is all that good.

I know the person reading this blog is wondering how they too can successfully waste tons of investor money. Well, luckily for you, I'll give you a sneak peak of some of the business strategies that have made us a negative profit powerhouse.

Never Say "No"

The first has to do with the fact that we're giant pussies when it comes to dealing with our customers. As an example, we had one of our installers call our technical support line when he was having a problem configuring his network. We didn't sell him anything dealing with his network. We weren't responsible for his network problems. He was having problems configuring his DSL modem. Initially we said we wouldn't help him.

The installer then called the CEO directly and pitched a fit. Since he's an A++ customer (our customers are rated A, A+, A++, A prime, and A++ super prime I believe) the CEO assured him we'd fix the problem. We spent a couple of days trying to figure out what his problem was and how it could be fixed, all for free.

Fly Someone Out

The next tip I have is for you to fly a person out to babysit any install, free of charge. Any time an installer has an issue with our product we like to fly someone out for free to do the install for them. Sure, we could try and work them through it over the phone but that wouldn't waste enough money. We could even require them to complete our training program before helping them. Again, that's just not realistic. We could even bill them something for the fact that they couldn't do their job. No, the better plan is to provide a way for them to get free consulting and install labor whenever they want (and it turns out they want it quite a bit). On a plus note, all of our sales and support guys have shit loads of frequent flier miles that they've amassed on the company dime.

If You Burn It, Just Return It

We resell some hardware components from other companies as part of our overall solution. We frequently have installers that don't understand electricity wiring up these components. As you might guess, they often fry the components by wiring them incorrectly. What's an installer to do? They can just return it to us, claim it never worked, and get a free replacement shipped to them overnight.

We then spend more time testing the returned equipment to verify that it is ruined. If we don't have time to test it, we throw it in a bin of test equipment for our QA department to use. Inevitably, they grab the damaged equipment, things don't work, then they report bugs on the software. The developers then spend time chasing non-existent bugs. It's all very well planned from the perspective of wasting money.

Sell It, Then Make It

The other way we screw ourselves is that our sales people promise customers that our product will do anything and everything (who doesn't have that problem?). On the rare occasions that they close a sale we're then on the hook for implementing something that didn't previously exist (for free of course). And, since it's already been sold, the time line for implementation and testing (ha! testing...) is extremely short. Finally, it's often a feature that no one else cares about. But, once it's in the product, it costs us money in terms of code complexity, maintenance, and testing time. It also prevents the developers from implementing features that a larger group of people want, which could theoretically increase the product's ability to compete long term. It's sweet, sweet genius.

Sustaining This Model

How can we afford to keep doing things this way? You might be tempted to think that we make it up in volume, but you'd be wrong. We usually just find a way to dupe investors into giving us more money. This is usually sold to them on the "Amazon Land Grab" model where you spend a lot of money to be the first business into a relatively virgin market. You build your customer base so large, so quickly, that it becomes very difficult for people to compete. Then, you crank up the profit machine and hire people to count your money.

The problem is we're not Amazon (those guys are smart), it's not virgin territory, and there's not enough money in the industry currently for us to make up the amounts of money we're wasting. Sometimes investors still fall for it. But, what happens when they get tired of giving you money? We'll talk about that next time.

Who Wants Some Popcorn?

I've mentioned Ike the sales guy before: "We'll call this sales guy Ike because 'Ike' has one good 'I', much like the sales guy." Upon further reflection and discussion, I think I have to rename this guy "Popcorn" because his mind works kind of like a bag of microwave popcorn. Nothing. Nothing. Then suddenly, a pop here, a pop there and then a flurry of activity. "Okay, now that that's done--Pop! Pop!" And then back to nothing. It's next to impossible to have a discussion with him in the room. For example, I decided to put up a PHP based content management system for internal discussions and such. For the next week Popcorn would randomly say "PHP-Nuke!" several times a day.

Our product integrates with some third party software that keeps track of some hospital related stuff. Let's say it's prescription history. This prescription history software uses an Access "database" to store its data. I don't consider Access a real database, that's why it's in quotes. We integrate by creating a view of some integration table in their Access install. The whole thing is very ill conceived and brittle. The version of the product that we integrate with supports exactly one station for updating and viewing this prescription information.

Our sales manager, that frequently hangs us out to dry and injects last minute requirements into upcoming releases, sells an install of our product that will integrate with the latest version of this prescription history software that supports multiple stations. He is, on some level, aware that we need a new version of the third party software so he orders a copy. Trent then schedules Popcorn to head out to the customer site four weeks later to make the install work. He apparently feels this is the end of his responsibility on the matter. Popcorn sits on this information for three weeks while the microwave heats up his idea factory.

Finally, a week before the install date, Popcorn mentions to one of the developers that he's planning on dropping this new, untested version of third party software into a new install. He holds the ignorantly optimistic view that it should "just work." The developer expressed some concern since it sounded like the third party software may have changed a bit. It may also have been several major versions of theirs since we used this integration feature. "*pop* *pop* Yeah, I'll probably try it out here first *pop*." The Friday before he flies out we ask him how the test went. "*pop* Oh, I haven't tested it. It shouldn't be any different. PHP-Nuke!!!"

He is once again warned about the fact that the developers all feel that it is a significant risk. "I agree," he says. "I'll probably try it out this weekend just to be sure." Well, he goes the weekend without trying it out, flies out to the customer site on Sunday and begins the install on Monday morning. Tuesday afternoon the developer gets a call on his cell phone. It's Popcorn. "Hey man, this shit doesn't work." The developer starts asking some questions about what's going on with the install and Popcorn hangs up on him. Thirty minutes later Popcorn calls back. "Do you guys have any ideas?" You can practically hear his little bag a-poppin'.

Again, the developer tries to get information from him and is hung up on. The next time Popcorn calls back we ask him what the hell is going on. "Sorry dude. The customer keeps coming into the server room so I'm hanging up so they don't think anything is wrong. You know what? Don't worry about it. I think I can get it working."

The next day we're in the middle of a department meeting when Trent bursts into the room and says, "Hey, this new install with the prescription history integration is blowing up all over the place. They're threatening to cancel the deal and rip all of our stuff out if we don't get it working by tomorrow." Given the circumstances I express to him the very real possibility that this won't be fixed by tomorrow and that he should begin thinking about alternatives. "Sorry guys, but we don't have an option on this one. We need to get this working. The whole deal is riding on this. We're painted into a corner," he says. You know, it'd be a little easier to take shit like this if 1) we ever learned from "our" mistakes, 2) we took risks seriously ahead of time, and 3) the person saying we were painted into a corner didn't have a wet paint brush still in his hand.

The development department breaks up the meeting, gets a copy of the new software, and begins to try and figure out what's going on with it. We get to the point that we've duplicated the problem when Popcorn calls again. "Any progress?" he asks. We tell him the situation so far when he tells us that he's gotten a patch from the third party and he thinks it fixed everything. We should "stand down" whatever the fuck that means. Trent tells us that he wants us to keep working on the solution. We can't seem to get the patch out of Popcorn but that shouldn't matter since he thinks it "just started working." The next morning we get another call from Popcorn asking how we're doing with the patch that he still hasn't given us. "It's still broken here, but I think this third patch is going to work." Since none of us locally have the first patch, aren't aware of a second patch, and obviously know nothing about the third patch we're all pretty much just watching the train wreck at this point.

Sadly (on some level), the third patch does indeed seem to fix the problem. This is the least satisfying resolution to the problem from my standpoint. Once again, the sales people chased a sale and their commission without thinking. They sold us into an install that we weren't prepared for. They didn't take the QA process seriously since in their mind our product hadn't changed. The sales guys didn't bother using their ample lead time of four weeks to try and resolve any of the issues, with or without development help. Then things blew up, we became a "team" and lucked out on the resolution. All this means is that from their viewpoint it was a success. Let's do it again on the next one. Yay.

In the aftermath the dev manager, Fredo, said that Trent felt really bad. Since I was feeling particularly mouthy I said, "Unless he feels bad because he's been fired and he's come to the realization that he doesn't have a sufficient skill set to get another job then I don't particularly care." Fredo is one of those managers that likes everyone drinking healthy doses of the Kool-Aid so I'm sure he didn't particularly like it. Luckily enough for him though he was able to read my not so subtle hints and keep his mouth shut about the matter. PHP-Nuke!

Character Study: Scooter/Bear

Since I'm so far behind on posts, this is likely the only mention of this person you will ever get to read. You should be sad at this as he was a rich source of material.

I have no good way of introducing this person, so I'll just do it through a kind of character study. I'm torn about what I should call him. He's a short, very hairy, homophobic, ultra-conservative, borderline racist developer that rides one of those Rascal-style scooters around the office. Apparently he's got really bad knees. I never miss an opportunity to make fun of the handicapped, even if it's something as minor as "bad knees." Therefore, I'm tempted to call him "Scooter." I know it's not very imaginative, but fuck you--get your own blog. Fine. We'll call him "Bear" instead.

Bear is a company man, through and through. He labors under the theory that there are smarter people than him with more information making intelligent decisions. I mentioned at one point that my unofficial contract with the company is that they don't make stupid decisions that jeopardize my job or the business. His response was to say, "Having a contract is all well and good until the situation changes and the company can't hold up their end." Huh-wah?

My primary gripe with Bear is that he sits in the cube next to mine and constantly talks to himself. It's not just that quirky "I'm a genius that thinks out loud" bullshit either. They're conversation bait. "Oh! I wonder what that means." "Oh! That's interesting..." I'm supposed to hear these and probably responsd with, "What's that, Bear?" An inane one sided conversation is sure to follow. When I ignore these long enough he generally moves onto, "Greg? Can I borrow you for a second? What does this non-error, non-warning message mean?" He adamantly refused to believe there was a timing bug in his code even after I tried to lead him through the overwhelming mountain of evidence. Several days later he was hobbling around like a proud little hairy peacock saying, "I know what it is. Yes. I found it. It's a timing bug." I want to slash the tires on his scooter so bad I can taste it.

Instead of vandalizing his ride I decided to just create a label using our label maker and stick it on his bumper. The first draft read "Honk if you're horny." After sneaking into his cube on my stomach to apply the label I decided that could lead to a whole sex talk with Bear that I wasn't emotionally equipped to handle. I snuck back into his cube on my stomach and pulled the label off. The final version that was applied was "The Rubber Duck. Puttin' the hammer down!" I was pretty sure he'd find it and we'd all have a good laugh at his expense. He went several weeks and never found it. He then vacationed to China and took the scooter with him. He still never found it. He came back to work with his airport cargo tag still attached with that stupid sticker still on his bumper. He worked several more months with the thing on it, got laid off, underwent surgery for a subdural hematoma (not related to the sticker), collected unemployment, found another job, and finally returned to the office to pick up some of his crap. Sure enough, that fucking sticker was still on the damn scooter. In my daydreams I picture people calling out "Hey there, Rubber Duck" as he rolls by wondering what they're talking about. It makes me sad that I'm not there for the payoff, but such is life.

As we follow an Agile methodology, we have a daily stand up meeting. Bear sits, of course, because of his bad knees. He also gives the longest summaries of the group that tend to have nothing to do with work. One meeting he brought in some piece of wood from a crib that he was building for his grandchild. He then proceeded to bang and slide it around the table while we were on a conference call and tell us all about his little woodworking project. Whenever someone is late to the meeting they pay a whole dollar. It's a minor punishment to remind people to show a little more respect for their co-workers' time. Bear decided he was going to pay all of his fines in change to further "punish" us for him being late. On several occasions he refused to pay rather than simply explaining that a work related activity had made him late. He often refers to his wife as "my sweetie" rather than by her name (I'm assuming she has one). He carries a cane and frequently mock threatens to beat people with it. Secretly I yearn for our work relationship to take a violent turn despite the fact that me standing over his limp body and beating him with his own cane would probably cause me to have to have a long talk with our HR person.

As I alluded to he eventually got laid off in a massive restructuring that unfortunately didn't eliminate my position. More on that in a later post.

While You Were Out...

Right before I had gone on vacation one of our sales guys, Trent, had sold a feature that we don't actually have. He assured all of us that if we couldn't get this sale the company was done for. It's always nice to be painted into a corner.

As background, we're at the end of a pretty big rewrite of our product. We just need to do some QA work and minor bug fixing and we'll be shippable. It'd take a month or two if we weren't constantly being called upon to implement customer one-off solutions for deals that never actually close. Meanwhile, the shipping version of our product is an accident waiting to happen. It'll do the job most days if you don't ask too much of it. However, it seems to be the goal of our sales guys to sell it into situations in which it is doomed to failure. This new deal was a great example. Not only did the functionality not exist in the product but adding it would expose some well known issues (namely that we use database transactions).

This was brought up repeatedly to the sales guys and upper management. Their solution was to implement the new feature in the shipping product and sell the buggy version with the hopes that the customer wouldn't get around to installing it until next year. By then, we will be able to put the requested feature into the new product (which should be shipping by then--keep your fingers crossed). When the customer is ready to install our product, we'll explain that one of their use cases requires the "enterprise" version of our product. Then we'll switch out the old version for the new version. Ta-da! Try as I might, I can't find any flaws with that plan.

Vacation

Just as HABSOC was ending, I went on vacation. I had postponed vacation until after HABSOC intentionally. I wanted the company to look good at the major trade show for our industry. The first Monday of vacation I woke up to a ringing cell phone. When I answered it I was greeted by the product architect telling me he had just been laid off. "They're laying off a lot of development. Deep cuts. Have a good one!"

To put this in perspective, the architect tends to exaggerate and I don't really care all that much about losing my job. It's a pretty good market these days. Plus, getting laid off on vacation would make for a great story. Alas, it was not meant to be. I dug through the list of numbers in my cell phone and discovered that the only number I had was for a member of the team in another office. I called him and asked him about the lay offs. "We're laying people off!?" Oops. I got the number of one of the programmers at the main office and called him. "Man, it's crazy here. They laid off the architect and our only QA guy. They also got rid of some sales guy. Fenrir's meeting is about to start. I've got to go."

Fenrir is the CEO if you'll recall. I shrugged it off and went about vacationing. At the end of the day Fredo gave me a call and said I shouldn't worry about my job and that we were making some necessary cuts. It all lacks a certain amount of excitement and suspense when you don't really care. I went about my vacation for the remainder of the week.

When I got back one of the other developers on the team was eager to tell me of Fenrir's meeting. The meeting was about how well HABSOC went, how it was creating huge opportunities, and how we had to lay people off. He apparently had a chart whose X and Y axes might have been time and how much money we have respectively (there were no labels or units of measure). There was a steady decline in money, a squiggle, and a sharp increase in money. You see, money was running out (the decline) so we laid people off (the squiggle) thus allowing us time to increase sales mysteriously (the sharp increase). The good news was that the schedule for the increase is "A+", whatever that means. He also screwed up the name of one of the people that was laid off. Unfortunately the name he gave is the name of one of the people that still works here. I'm sure that got a good laugh.

Lay offs concern me most when it's a whole position or department that is eliminated. To date we had lost all of our QA guys (we still have a manager), our dev manager, our docs person and our architect. Luckily we still employ the people responsible for booking travel for the sales people, roughly one executive staff member per regular employee, and the person that orders all of our sodas, granola bars, and Rice Krispie Squares. Thank god. For a minute I was almost worried that we weren't being A+ about these lay offs.

The Show Must Go On (Part 3 -- Finale)

The day after the Dancing Bear demo, Friday, everyone needed to get out to HABSOC and set up the booth on Saturday and Sunday for the first day of the show on Monday. Ike took off and left the borrowed card reader for someone else to take. I hunted down another sales guy and loaded him up with it. Next, the IT guy took the new printer with him so he could use it at HABSOC instead of the one that was already out there. He thought it would somehow be a better demo with the new model. He's wrong, but whatever.

I get a call Sunday from Ike at HABSOC. Apparently the card reader's configuration changed in order to get the boardroom demo to work. He hadn't paid attention when I explained that I had already set up the HABSOC demos to configure the reader, just in case they needed it. He just needed to click on the shortcut that said "reconfigure reader." After that was out of the way he let me know that the IT guy was having problems with the new printer and had unfortunately done something that caused the old printer to no longer work. But not to worry. Getting the new one working "should be easy." Eventually they got the printer working to everyone's satisfaction. Never mind that both the reader and new printer were risks that could have been easily avoided. If everything actually turns out okay then your risks were only another case of developer "chicken little" syndrome. It kind of makes you wonder how these people make it this far in life.

While at HABSOC we bought a large plasma screen for presentations in the booth. We bought it and shipped it straight there. It arrived, we used it. The show went well. At the end of the show, someone boxed up the plasma in the original packaging (also known as the "steal this box" box) and left it on the trade show floor. Oddly, when we got back to the office in San Francisco the display was missing. Upon further investigation, no one knows where it went. Oops. It doesn't help that all of the sales guys were joking about stealing it before the show.

Before all of this crazy shit started happening, our doc person quit. We just moved those duties onto the development manager. Our support guy quit. We moved those duties onto sales and development. We laid off / fired the development manager (and doc writer now) and moved those duties onto the architect. We let everyone know that sales were a little flat. We put the HABSOC booth together. Two developers quit. And finally, I went on vacation. I could hardly wait to see what happened next. Surely nothing bad?

The Dancing Bear

After the HABSOC booth setup shipped we had a week of time to actually work as developers. Or so we thought. Since the CEO had said that he wanted a duplicate of the booth demo in the board meeting room someone had to put that together. Sales hadn't really participated in the construction of the demos or configuring the equipment for the booth so they didn't really know how to set up the board demo. That meant that it would likely fall to development again. Which again meant that some of us wouldn't be programming for a little while longer. The secret codename given to this demo by our architect was "The Dancing Bear." The idea being it doesn't matter how well the bear dances, it's a miracle it's dancing at all.

Another developer and I along with a sales engineer (we'll call him Blinky since he has a nervous twitch that causes him to blink almost constantly), Fredo (my boss), and the CEO all had an impromptu meeting to iron out the details. We need a nickname for the CEO who happens to be from Norway (as far as you know). Fenrir seems good enough. Descended from the god of mischief and strife, bound by the gods (the board members), but is ultimately destined to grow too large for his bonds and devour Odin (our company). Yeah, that paints a pretty accurate picture. Fenrir tasks Blinky with putting together the board room demo. Since Blinky simply can't do it, it's understood by all that the other dev and I will do the work and show Blinky what we did after the fact so he can maintain it and improve it. Of course, Fenrir doesn't really want a duplicate of the booth, even though that's what he said.

To get to the bottom of what it is we'll be doing, I ask Blinky to rank the seven demos in order of importance for the board demo. That way, we can work in priority order and we are more likely to successfully deliver the most important items. This is called "common sense" in some circles, but not this one. Blinky takes the out of date Excel spreadsheet with the list of five demos the sales guys were supposed to deliver (and didn't) and begins working on it. After a few minutes he says he thinks he's got it. He proudly explains, "I've marked these demos with a check and these other ones with a check plus. This one is a check minus."

I look at the other dev who looks right back at me. We both look at Blinky. I look at Fredo who smiles and nods with satisfaction. Although I'm very impressed at this new "base check" numbering system he's invented, I try again by saying, "Okay. Oh, those demos are out of date. Here's a list of the seven demos that are going to HABSOC. Just number those one through seven with one being something you feel you must have for the demo. Item number seven is something you would still like to have but is less important than the numbers that come before it."

After a few more minutes I get, "These three are number one. And this other one we really need. And I'd like the other ones."

"Great. That's a very good start. I'll just go ahead and number these in the order I think is most important. We'll go through them one by one and you can let me know if it should be higher or lower." I figure this is close enough to The Price is Right to make sense. I'm just hoping he doesn't make the connection and mysteriously bid $1. We finally get through the list and determine that we are on the hook for delivering items one through four. The rest can be done later but they don't have enough "sizzle" to be high priority. That's their word. I'm sure they had a meeting and agreed to begin working it into sentences because I heard it roughly ten times over the next five minutes.

The other dev and I pounded out an equipment list over the next fifteen minutes or so. Since we'd depleted our stock of "extra" stuff (also known as stuff we stole from other less important departments--like QA) while building the HABSOC demo, we felt we would need to buy this stuff. We all looked at Fenrir who smiled and said, "Of course. Money is not an object. Look guys, this is something we can show that people will say, 'Fuck! Look at how fucking good this is!' That's something. Let me tell you." Apparently he loves to swear when he's making up dialog for fictional people. Plus English is his second language (at least) so I think the swearing has less impact for him than the people he's talking to at the time. It doesn't bother me personally since I love to swear but I could see how it might not be a great trait for a CEO.

Blinky was tasked with getting us the necessary equipment. A fact that he was quite happy with since it meant he could rack up some airline points with his personal credit card. Before the meeting ended Blinky turned to the other developer and I and asked, "So when will you guys be able to get started?"

"We can start doing something when we have the computers. When will we have the computers on the list?"

"That's what I want to know," Blinky responded.

"Dude, you're the one buying them."

"That's right. Okay. Like I said, I can have the stuff by Tuesday." I guess if something isn't actually on fire it's very hard for some people to pay attention. Go figure.

We all ended the day feeling like we had made the best of a bad situation. Dev would create the demos in priority order, buying equipment as necessary, and the other groups would stay out of the way this time.

In the morning Ike, the head sales engineer, came in and once again got his panties in a knot over development trying to steal the show. He nixed everything on the equipment list and determine he could do nearly everything with equipment borrowed from other departments. He then stole the card reader from the HABSOC demo (see previous post) with the intention of using it for the board demo and smuggling it onto the trade show floor. The only item that had to be bought was the special printer we needed for one of the demos.

Next, he added the only HABSOC demo he actually worked on back onto the list of priority board room demos. So now there would be five demos. We could work on them all simultaneously to save time. He explained how this wouldn't add to the risk since we had already cobbled together the demos for HABSOC. This time it "should be easy." The other dev and I washed our hands of this and told him to go ahead and let us know when he needed our help.

This was on a Friday. The demos needed to be done by the following Thursday. The IT guy spent most of Tuesday getting the new printer working. It was a later model than what we sent to HABSOC so he had to figure everything out again. Late Tuesday Ike discovered that he needed to buy a bunch of equipment from the original list. Apparently we didn't have most of the stuff he thought we did. He seemed mildly confused at how the other developer and I had missed this fact. He finally got the equipment together and working on Wednesday. He was still having problems with his extra demo but he was now ready for the other dev and me to go ahead throw together our four demos. We put our stuff together and walked him through using them. He managed to get his stuff working and the demo was ready for Thursday.

Fenrir made the little bear dance for everyone. Happiness ensued, despite everyone's best efforts.

The Show Must Go On (Part 2)

One of the demos we decided to send to HABSOC involves a special printer for printing things related to hospital billing stuff. I know that may be getting a little too technical and may even be giving out some of our trade secrets, but I think it's important to the story. Development had seen the need to get one of these printers about a month out from the trade show. No one had gotten this printer to work with our system to date. No one had really tried. It was a big unknown.

Every time we brought it up though someone would say that it was covered. One of our executives has a demo unit on loan from the company. We can just use that one. We just need to flash the firmware and do some special configuration magic. And then, no one would do anything about it. When confronted with the fact that we'd never tried to get the printer working the response was, "It should be easy." Of course, it actually won't be since it's not a normal printer.

It went on this way until the week we were supposed to pack stuff up and ship it to HABSOC. Finally, one of the sales engineers starts looking into it. She prints out 17 pages of instructions on how to get this thing up and running. When she gets all the way to page 2 she comes to get me to let me know that she doesn't know what the fuck is going on. Luckily for her neither do I. When I bring this up with her boss he assures me that she's on it and that "it should be easy."

Finally the IT guy stepped in to get the job done. In order to do this he needed to get on the exact machines that the demos were on. Now. Right now! He needs on the machine!! Not a machine like it, THAT MACHINE!!! MOVE!!! This derails devs' work effort of putting stuff together for a day and a half while he gets this printer working. When he finally has it working he let's me know that it was easy. You know, once he got past the day and a half of the hard stuff.

At the end of the day on Tuesday (we have to pack on Thursday, ship on Friday) we are done. We hand it off to Ike the sales engineer who then does his dry run for the first time in front of the executives. He stumbles through the demo, but overall it comes off pretty well. At the end I can hear everyone present saying sentences that begin with, "You know what would be cool..." Yeah, I do. It'd be cool if you had paid fucking attention a month or two ago when we were talking about these demos. Then we could implement some of these ideas. Hell, I'll even say that it's hard to know what you want until you see a first draft. In that case we should have worked on these demos a month ago and gotten feedback then. Bringing it up now is pointless.

Finally, the CEO begins rambling incoherently about how this is a world class demo. He should issue a press release. And he wants the exact same demo set up in the conference room so he can demo it to the board exactly one week from that day. He also wants to have an "always ready" demo of all of this cool stuff. This whole adventure warrants its own post and will be seen at a future point on this blog. I mention it here because a one point will become important for HABSOC in a short bit: he'll need special card reader we use in the billing software. It's a simple reader that we can order from a variety of vendors and get well within the week if we expedite it. Total cost would be $2,500. However, we've really needed another one of these for some time as we only have one in house. The CEO says it won't be a problem because money isn't an issue.

The booth setup is proclaimed as done. We begin packing things up on Thursday as per the schedule. At this point Trent, the sales manager, wanders in and says, "Um, did we remember to get screen shots of everything?" You know exactly what that "we" means, don't you? All the developers point out that it wasn't on the schedule and that today is the day we are supposed to tear it down so it can be packed tomorrow. He wanted screen shots in case the board room demo didn't get done in time. He just either expected us to guess that and do it for him or he didn't pay attention to the fact that there was a schedule. At this point he starts strolling around the area while talking loudly on his cell phone. It's obvious that we're intended to overhear that he's tattling on us to some unknown party. When this fails to elicit a response he gives up and wanders off.

The thing to realize about HABSOC is that the equipment delivery and setup is a very tightly controlled union job. You aren't supposed to bring in equipment from the outside--it has to be delivered in the crate(s). If they catch you bringing stuff in they apparently get very angry. Originally we were scheduled to deliver one crate of stuff. This was estimated from when the sales guys were in charge of the demo. When dev got involved and found out how much equipment it would actually need we found out it would require two crates. Not a huge problem, just a pain in the ass for our operations guy. The fun part comes into play when he starts packing things up on Friday and I notice that the card reader is missing.

Someone swiped the card reader from the HABSOC pile so they could use it for the boardroom demo. HABSOC is once a year and is very important to our industry and therefore our company. The boardroom demo happens once a month and in my opinion could have waited. The other option was to spend money and buy another reader (which we need any way). All of the sales guys and their managers assured everyone this would be the best way to do it. This way we don't have to spend the $2,500. Do the boardroom demo next Thursday, then smuggle the reader onto the trade show floor and wire it up. I bitched about this as a wildly unnecessary risk to my manager, Fredo. He's been looking for an opportunity to prove his worth. Fredo, puffed up and "confronted" them. After the confrontation he assured me that it would be best this way and that it actually made sense to take that great of a risk with the trade show. You see this way, we get to shop around for a better price than the $2,500. Hell, maybe we'll find a coupon or something. I finally let it go, comforted only by visions of sales guys getting their fingers smashed by hammer wielding teamsters. A vision that sadly didn't come to pass.

Be sure to join us for our next and final HABSOC installment. I'm desperately trying to catch up to the present here so please be patient.

The Show Must Go On (Part 1)

For those of you that don't follow the fast paced world of hospital billing systems there are, let's say, three big hospital management trade shows throughout the year. The big one is at the end of August--the Hospital Administration and Billing Software Convention or HospAdminiBillSoCon for short or HABSOC for super short. Our company was going to have a booth at the convention this year which is held in Topeka, Kansas (the hospital billing software capital of...Kansas, I guess). Of course our sales guys were responsible for putting together the booth which was to contain several demos of the exciting functionality in our application.

You have to ship your booth contents to the show a week before the convention. We had to have a manifest for the equipment we were shipping on a Friday, pack the equipment the following Thursday, and ship it the Friday immediately following (to be delivered a week later and set up by the sales guys since no developer would be attending the show). That's one week to get our shit together. The sales guys were adamant that they would handle putting together all of the demos, about five in all. They pissed away a month and had a list of five demos that were pretty much identical to the same shit we always demo. They weren't too firm about assigning responsibility for putting together these demos, acquiring equipment, or even coming up with any kind of a deadline. They did, however, have the list in Excel which made it feel pretty darn official and efficient. Finally with two weeks until the show the development team began to express some concerns. We drew up a list of potential issues and ran them by the head of marketing along with some much better (flashier) demo suggestions. We were assured that no one was interested in our cute little demos. As for the concerns, one by one he "addressed" them by saying that it was being handled.

The only thing the sales guys had done up to this point was get a server. Of course, it was a bleeding edge powerhouse with four 700Mhz processors that our IT guy was trying to sell us from his private collection. Normally I would be worried about a heat problem with a server that has almost as much horsepower as my desktop, but luckily it had a CPU fan that was only slightly louder than a jet engine--sure to be a hit within the confines of our booth. And as another plus, maybe we could hand out free earplugs with our company logo on it. Our company name has a ring to it, just like your hearing. Zing, zap, pow!

The remainder of the concerns were going to be handled when several of the sales guys would sit down on a Monday (the Monday after the Friday when they were supposed to have had the equipment list) with a couple of laptops and throw something together. We'd learn later that our competition showed up on site with carpenters and built a two story booth on the trade show floor but that's only important to illustrate our company's extreme incompetence.

Suddenly it began to feel like a big game of "responsibility chicken." Anyone willing to accept the very real possibility that our company would look like shit at the trade show would be off the hook for doing the work. Development blinked and started putting together the demos from some previous work we had done as iteration demos. One by one each demo became dev's responsibility as a sales guy would mention in passing that they wouldn't be doing one of their demos and that they'd be using ours instead (which they had insisted they didn't need or want us to work on).

Finally we just started putting together the mock up of the booth. We taped off an area the size of the booth and duplicated the booth layout, complete with multiple tables matching those that would be provided at HABSOC. At this point the loudest and most abrasive guy from sales got his weenie in a knot because development was trying to take over his stuff, as if he couldn't do his job. We'll call this sales guy Ike because "Ike" has one good "I", much like the sales guy.

From that point forward, Ike would "help" us out by doing things like changing the VNC passwords on the servers (the servers that had no monitors because he insisted he didn't need them or a KVM (to which he later said he never said that)). Ike was also useful for doing things like taking rack mounting hardware from our production servers to put in the small mobile rack we had for the show--the one we bought from the IT guy from his large collection of surplus Soviet era computer equipment.

Ike was also great in that he tasked us with buying some more RAM for "his" server. A developer paid for it out of pocket (to be reimbursed later) along with another $350 of assorted "oops we need one of those" items. This happened because everyone with a company credit card mysteriously disappeared when it was time to go shopping. The real fun began when the developers installed the RAM and sat the old RAM on top of the server rack. The QA guy grabbed it for the QA lab since it wasn't being used. For the next week Ike would ask several times a day where his RAM was. No one seemed to know. So, Ike waited until one of the developers went on vacation and accused her of stealing the RAM. Yep, that's what happened. She stole his fucking RAM! That was the only logical conclusion. He then went up and down the hall talking loudly (even for him) about how that damn developer stole his RAM. The RAM reappeared after this of course. When Ike was asked about maybe apologizing the response was, "For what?"

"Well, you accused her of stealing when she wasn't even here to defend herself. Where was your RAM?"

"That's what I want to know," Ike replied.

"Don't you have it now?"

"Yeah. Exactly."

There you go. In all fairness, he thought she was a dirty stinking thief. Why would you apologize to a thief?

So ends Episode I (maybe I should start with IV) of the great HABSOC debacle.

So Long and Thanks for All the Features

Most of what I know about the actual firing of the development manager has been pieced together after the fact, mostly by infiltrating sales department happy hours (company sponsored, of course). After numerous sessions of stuffing my face with pizza shooters, shrimp poppers, and even the dreaded extreme fajitas I found that the perception is that the development manager was a huge barrier to progress.

The DM had an annoying habit of insisting that people rank desired functionality (and no, not everything can be tied for first) and then trying to work top priority items into the next two week iteration. This was described directly to me as "not agile enough."

Back when Trent (the sales guy) ran development we used to have sales guys call programmers directly from the site of potential customers. The sales guy would then describe the one feature our product lacked that was preventing the software from virtually flying off the shelves. The programmer would then take up to a week to implement it, cut a build, possibly increment a version number (not required), and we'd install it for a customer. Inevitably we'd turn up problems either during QA or at the customer site (pretty much the same thing). So, we'd patch it up a little (by changing multiple things at once) and cut some more builds. When that wound up breaking more things the customer would then threaten to pull all of our software out and kill the deal (for which they still haven't paid any money). We'd fly out more sales guys and try to babysit the install. Eventually the "customer" would calm down and agree to not rip our stuff out. They typically would never buy any more of our stuff, probably never paid for the stuff they got, and could be used as a neutral referral at best. After 6 months or so this would internally be held up as a success story.

Failure by the DM to stick to this proven method of delivering the product caused a lot of friction. So did starting meetings on time without "rounding up" all the interested parties that can't manage their own calendars. So did trying to stick to meeting agendas and not allowing everyone's time to be wasted by marketing stream of consciousness incidents. So did telling people their ideas wouldn't work and that there are better alternatives. So did trying to insulate developers from repeated interruptions by other company members (this got him the nickname "the Iron Curtain"). The ultimate final straw though appears to have been a personality conflict with the new VP of engineering.

The previous VP of engineering fled the scene of the crime and hand picked his own replacement who happened to be an ex co-worker / buddy that needed a favor in the form of a new job. The only person I found that interviewed the new guy recommended against hiring him. The new guy had zero technical background, didn't understand the industry, didn't understand the product, had screwed over some of the current developers in previous jobs, and had a somewhat weak personality. If Fredo Corleone had succeeded in taking over the family in The Godfather: Part II, I think it would have looked a lot like our engineering department. In fact, we'll call the new guy Fredo in honor of that theory.

Fredo had a problem with having a non "team player" reporting to him. Team players don't just drink the Kool-Aid they help mix it. This company has no place for people that won't delude themselves and those around them. The theory is that Fredo called up Hyman Roth (the previous VP) and was instructed to cut the cancer out. The DM's ominous sounding prediction that he was about to be fired came true a couple of days after it was made. The all new Dark Ages of the company were about to begin.