Archive for the 'Technical Difficulties' Category

Winning Big

June 6, 2008

I had scheduled a meeting with David, our CEO, several times in the past weeks, but on Monday, after being stood up on all those occasions, I finally just walked in to his office and started talking, which worked out in an interesting way.

It turns out that many of the concerns that Walter had were echoes of David’s concerns. Also, as I thought, Walter had been under pressure to complete other tasks he had, so it was all a bit overwhelming to him.

The particular concerns he had are a topic for another post.

The interesting thing was that I got to explain, in my view, what was going on to David, and without prompting, David asked me if I wanted to take ownership of the project, which was one of my goals for the meeting anyway.

He asked me what the cost of the system would be, and how much time it would take. When I told him, he said, “Ken, I want you to win big on this, but I need to know that it will happen.” Then he asked me if I’d bet my paycheck on it — and he meant it.


Climb with Care and Confidence

To answer him, I looked him in the face and I told him I would, yes. Even though I know that nothing is certain, I also know that bosses prefer overconfident managers. Using that knowledge, I knew not to equivocate– “Well, sort of… I guess, if…”

I said, yes, I would. Given the choice between betting my paycheck on Slomo or AwesomeSoft, I choose to bet on AwesomeSoft.

In response, he gave me the responsibility for the project. What is the risk in telling him to fire me if the project doesn’t go as planned?

Let’s play a little game theory.

Take Responsibility Reject Responsibility
Project Fails I lose my job, and I get another one. I continue to suffer under the onerous burden of not having any infrastructure for my team.
Project Succeeds I “Win Big.” Nothing happens to me. I get the system I want, and I am in roughly the same political position.

Let’s explore what that matrix means

  • If I have utterly misstepped, and in my arrogance recommended a system and a vendor that are going to fail, I risk being fired. If that happens, I may not be able to find a job at my current salary level, but I will be able to find one at an acceptably high level, so the stakes are fairly low here.
  • If I do not take responsibility, the project will fail. The path that Walter is headed down is a dead end. He’s considering going with a scuzy, proprietary vendor to get mediocre software that will not fit the needs of all departments, and will not scale for the future. That means the scenario of my not taking responsibility for the project ends the same way every time: I still have my job, but it’s doomed. I will not have the tools to build a strong team, or to meet the regulatory requirements that the government has set for the software I’m tasked with building. If I let this project go by the wayside, I will lose my opportunity to become the technical leader at Ideal because I’ll be bogged down indefinitely.

So, what looked like a risky proposition — staking my career at Ideal on something that is uncertain — actually turns out to be the only reasonable alternative to beginning an active job search. If I didn’t take the risk, I’d be almost certain to fail at my job, that same way that taking the risk is almost sure to save it.


Pressure to Perform Miracles

June 2, 2008

As I discussed previously, Ideal needs a complete overhaul of its technology systems. There is an unintended consequence of making everyone believe I’m solving only their individual problem, as I explained in Technical Bankruptcy post. It is that they all conceive of my project and the effort involved with it in terms of only the portion they are interested in. They expect Emerald to be complete in the time it would take just a permissions system to be done, or just a visual overhaul to be done.


The reality is that before any of those individual pieces could be built, I had to design and document an underlying architecture that would support Ideal’s needs for years to come. I am doing the work of several architects and I’m doing it in a fraction of the time it should be taking. Although I am confident in the quality of the system I am building, I am personally nervous that I’m overlooking something, because it feels an awfully lot like I’m working a miracle.

I need to set the expectation in the organization that this is a medium (not short) term project, and try to solicit the limited and supervised involvement of the developers I have right now in order to make this work.

Dragging Ass

May 30, 2008

As of this writing, Walter has been dragging his ass for three weeks on a new information system that I’m trying to get implemented for Ideal. The system is fairly complex in that it must meet the requirements of several different departments with existing infrastructure, and be able to handle future needs as well.

Angelic Choir

This is not something I took lightly — almost as soon as I got here I identified the need for this system and began gathering requirements from all the departments. I researched vendors heavily, developed a short list of four vendors who could deliver, then asked for estimates. I targeted the most promising vendor, negotiated the final contract, and delivered it with a Hersey’s Kiss to Walter’s desk. I could here the faint melody of an angelic choir as everyone in the company rejoiced.

Then we waited as Walter fumbled from one excuse to the next. We watched as days turned to weeks. The departments are being crushed under the pressure of 20,000 Leagues of bullshit that they can’t keep organized, and my vendor is bucking at the starting gate.

I’ve talked to Ben, our CFO about this in the hope that I can uncover what must be the hidden obstacle. There is no obstacle — Ben says if I need an officer’s signature, to bring the contract to him, and he’ll cut the deposit check. I’m being encouraged by other players to just do it without Walter’s approval. People are in pain.

Over worked and Overwhelmed


My suspicion has been confirmed. The unseen roadblock that is causing all this pain is psychological. Walter is not a technical guy — he excels at organizing systems, and creating paper trails. This responsibility has fallen to him by default: before I came, there was no one else to do it. Now Walter is drowning under his normal workload (ironically, because this system is not in place), and he is overwhelmed with technical information he simply doesn’t understand.

It’s not his fault. It’s a common psychological effect: too much information about an important decision will cause a person to freeze, unable to call the shot.

To overcome Walter’s brain freeze, I’ll go to David, and tell him what’s going on, tell him why I think it’s going on, then make the move to take the responsibility off Walter’s shoulders entirely.

If it works the way I hope it will, I will get the system up, and be one step closer to having the final authority over technology issues here at Ideal.

Technical Bankruptcy

May 23, 2008

The mess I have inherited here at Ideal is technically insolvent.
Dodge Charger

I knew a guy a named Bill few years back who had a brand new Dodge Charger SRT-8, which he paid $850/mo for. He loved that car. He cleaned it meticulously (the only thing he was meticulous about), he drove it incessantly, and he became so attached to it that he eventually lost it.

After adding insurance, gas, and other bits and pieces he sunk into the car monthly, he was throwing more than half his income away. When it became increasingly difficult to pay his rent and other bills, he just couldn’t trim the budget – he loved the car so much that he started eating into his credit to make ends meet.

The situation became worse when he started opening new credit accounts as the others reached their limits. The minimum payments on his 9 separate cards added up to more than he paid for is car every month. When the credit ran out, he was sunk. Stuck with debt that was over half his annual income, with living expenses outpacing earnings, he has to choose between his roof and his car.

By the time he parted with his beloved car, it was too late. He still had to have a vehicle to get to work, so net monthly savings was only $600, while his new credit bills were over $2,000 a month.

This is insolvency: having greater debt than assets. Bill had more bills every month than he could pay, and it was because he didn’t spend wisely. Luckily for Bill, in America we have bankruptcy instead of debtor’s prison.

Behind Bars

Coined by Ward Cunningham, and introduced to me by Steve McConnell, Technical Debt refers to borrowing time on software projects in exchange for quality. Any time we want to add a feature to a piece of software, we are faced with a choice:

“…one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.” – Martin Fowler

Briefly, Technical Debt is similar to in character to financial debt:

  • You have to pay it back with interest. When you cut a corner, you eventually have to go back and implement the feature correctly. By the time you do, there are other parts of the project that are dependent on the corner you cut, so it will actually be more difficult to write correctly. Prior to that, changes you make to other parts of the software will be made more difficult by your poor design. This is the interest.
  • Long and Short Term. Short term debt, much like a credit card, is often unplanned, high interest, and should be paid off quickly. In other cases, you can borrow strategically with a plan to pay it back over time. This is like writing a quick and dirty prototype in order to be first to market, then using the financial momentum to rewrite.

If there was a technical debtor’s prison, Ideal would be behind bars. Poor management and poor programming have piled loan on top of loan, and now, like Bill, our interest payments are greater than our income – the principle is growing, and we don’t have the assets to pay it all back. Practically what this means is that our software products have grown out of control, and our programmers time is consumed with a growing list of critical failures and bugs streaming in from increasingly irate customers. We don’t have time to fix the outstanding issues, never mind improve the software!

Prison Break

Prison Break!

I realized that the situation was not salvageable about a week after I started work. That’s when I began quietly gathering requirements, and creating a completely new architecture. This is dangerous territory. I’m flying against the prevailing wisdom of our field by doing a potentially ill-advised rewrite, and I’m doing it under the noses of the guys who wrote the bankrupt software.
I thought very carefully about the rewrite, being aware of the reasons not to do one: that was technical decision best left to another article. The political issues, however, are human, not technical. The fact is that if a new person comes into a group and says “Hey everyone, the work you have been doing for the last few years is awful, and I’m going to redo it,” he will be universally despised.

What I chose to do instead was listen to the guys, and find out what they thought. They had many pain points as they bore their onerous technical burden from one dismal release to the next. Each time one mentioned something that sucked up their time, I was quick with: “Wow, is there any way to make that better for you?”

As an aside, I knew this question wouldn’t get a good answer. If these guys were capable of planning easily maintainable code and articulating solutions, Ideal wouldn’t be in this situation. Invariably, they say “I don’t know, I can’t think of anything…”

That was my opportunity to offer a suggestion like “Well, what if we could [idea here], and that way you wouldn’t have to do this anymore, and you’d have more time to do [fun activity]?” When I said something like this, I was met with cautious enthusiasm like “That would be great… if it ever happened.”

“Let me work on that for you,” I’d say. Often my off the cuff idea had already been implemented in the new architecture. For example, we have user permissions that control access to the functionality in our software. Right now those permissions are hard coded, so that to change the permissions a developer has to change code and recompile. The better way to do this is to store it all in a database, accessible through an admin interface so our implementations people can do it without bothering the developers. This was planned well before a developer on the team lamented the situation, and I took the opportunity to get him excited about the possibility of the admin interface.

Champion of the People

The result is that the new software is different things to different people. Each person has a unique set of expectations that I’ve tailored to them in particular. Some people are looking forward to automated licensing, others user permissions. Other people are looking forward to whole thing being packaged so that it can be installed with one mouse click instead of arcane voodoo they have to work now to get systems running. Everyone feels like I’m working on something just for them, that will be designed to solve all of their problems specifically.

By the time I’m finished, it will be the software package Ideal needs to move forward instead of sinking, and everyone will be thrilled that I’ve built something just for them. Undermine peoples’ natural territorial feelings by carefully soliciting an invitation into their territory.

Acme, Inc.

April 10, 2008

Acme Inc. is a Fortune 500 company servicing insurance clients. We built dodgy software that our executives sold to our clients’ executives during cocktail parties. Office cogs used our software to handle claims on the front lines, and the executives who originally made the deal never had to see or use it. That is why the quality of our work as software developers didn’t matter at Acme: the buyers were totally disconnected from the users, and all the buyers cared about was budget and deadline.

You may recognize this scenario in your own work: you are trying to do the best job you can, and the brass talks a good game about quality products. They wax poetic about robustness, and best-in-class, or whatever marketing drone bullshit is common in your particular industry. Then, those same managers set up the department to reward speed and totally disregard quality.

Read the rest of this entry »