In Shock!

I have spent twenty one years earning my living as a computer programmer in corporations. One of the givens that I have encountered is that the annual performance review will be a travesty of documentation that bares no resemblance to what you actually did. Generally, they are a way for the manager to let off steam and blame you for anything that they think makes them look bad.

I had my annual performance review today and I'm in shock. My manager (actually a Director, but who's counting) wrote a magnificent review that was an accurate representation of my years activities. She even remembered some things that I had forgotten I'd done. She thanked me for all my hard work this past year and expressed her belief that I would do well this year in my new role as a Team Lead for my area.

It was a good job I was sitting down!

Quick! Give Me An Estimate!

I'll see how short I can keep this one. If I don't try to keep it short, it might turn into a major rant and then I'd feel that I had to publish it as a book.

So there I am talking to a co-worker this morning and we're exchanging stories of management insanity. It's one of our favorite topics and virtually guaranteed to never run dry of source material. He tells me that he talked to the new big boss who wanted an estimate for some work that needed to be in production at the January deploy.

For those who may not be used to the way things work in Corporate America, let's revisit that one in slow motion so that you can admire the sheer talent required to ask a question of that nature with a straight face.

We're pretty used to being asked for estimates in the IS world. We're also used to having those estimates ignored, but that's another rant for another day, so the question doesn't seem out of the ordinary at first. The jaw-dropping display of audacity comes when the manager slips the answer they want on the end of the question. Did you notice that?

It must take a level of poker skill beyond the ability of mere mortals to construct a question that includes the only permitted answer. The asking of the question in the first place is only to give the programmer the momentary illusion that their opinion is valued and then the realization dawns that it doesn't matter what your estimate is, because there are only a finite number of weeks/days/hours between now and late January.

I don't think I've ever pulled off a trick like that and I'm pretty certain that I'd never want to. Even while I can recognize the immoral nature of the question, I must concede a certain initial grudging admiration for anyone who can pull it off. After that, I just settle back into my normal bitter and twisted cynicism for all things Corporate.

One Trick Pony

There I was teaching at our mid-week service last night and I was describing how Satan pretty much comes across as a one trick pony in the scriptures. While he does have powers and a number of them are described, he tends to stick to the one that works best against us humans.

Sometimes, certainly not very often, I wish that the evolutionists were right and that we humans could evolve to be a little smarter than we seem to be right now. You see, Satan worked Adam and Eve over in the Garden of Eden using only a lie. He sowed doubt and discord into the first man and his wife by questioning the word of God and using a few "fake but accurate" statements.

Satan is still using the same trick because it has worked so well for most of history. He still lies and many of us still believe him, despite no history of truth on his part. This is distressing to me as I keep hoping for better from my fellow humans.

Naturally, in the more enlightened environs of Corporate America, no such thing could ever take place. Right? I mean, with all those managers with MBAs, it must surely be an impossible thing for a lie to last 5 minutes in the full glare of an analytical management team? That's what I used to think. Then I observed our current contractor group in action.

The leaders of our primary onsite contractors have exactly one line that they use again and again and again. They do have another one, but the first one works so often, that they nearly always forget to use the second one.

When we, the customer (you know, the folks who are in charge), ask for something and specify any detail that they don't like, they come right back with "That will mean we miss the deadline." and our management fold like a limp rag. It's an amazing (and frustrating) sight. It's like watching the strings being cut on a puppet. One minute they're standing tall, laying out requirements and specifying how things should be done and the next minute they're backpedaling and saying words to the effect of "Oh! Really? However you need to do it then. That'll be fine."

While the pony may have only one trick, it's quite effective! Unfortunately, the same trick doesn't seem to work when we employees try it. Oh well.

Sick Days

Sick days are funny things in Corporate America. Being sick generally isn't funny, but the games that companies play with their HR policies to try to prevent rampant abuse by a few unscrupulous characters is borderline hilarious.

Back in the old days (or at least at places where I have previously worked) salaried staff just took sick days as needed. If you were sick enough to go to the doctor, you got a note and presented it to your boss when you dragged yourself back in. Abuse was pretty low, because only salaried staff could do this and back then managers would actually watch your sick days and make honest judgement calls as to whether you were really just having a bad flu season or that you were "swinging the lead". This seemed to work pretty well.

Then came the concept of the timebank and logic seemed to rapidly leave the building. The timebank feels like a devious way to try and get more work out of the employee. By taking the old-fashioned concept of vacation time and adding a few days to it and calling it a timebank or the trendy acronym PTO (Paid Time Off) the companies now penalize sick employees by forcing them to use valuable vacation time for reasons other than rest and recreation.

Naturally, this concept has backfired and as could be easily foreseen, the fact that it has is completely lost on the HR folks. In the same way that being forced to work extended overtime causes people to compensate by taking longer lunch breaks to allow them to run their errands, the lack of real sick days causes otherwise sensible employees to drag themselves into work when they are sick.

This is a problem because sick employees are less productive in terms of real work and there is a huge chance of them infecting their co-workers. It only takes a few of these "heroes" to drag themselves to work during a round of sickness to seriously affect the productivity of a team or even an entire office.

The irony is that most management equate seeing you with knowing that your working. This is obviously not true, but it is their primary metric for deciding whether you are a slacker or not. So, even though you're running to the bathroom every half an hour and getting through tissues like they were going out of fashion, you are seen in the office, so you must be a good employee. No account is made that you are likely less productive at your work, and highly productive at infecting those around you so that they can be less productive for the next few days or week as well.

If companies would bring back the old-fashioned sick days, they would greatly reduce the amount of sick time that they currently endure by allowing sick employees to stay home and recover and not infect co-workers. Obviously sick days would have to be watched to prevent abuse, but adapting the advice to "let sleeping dogs lie", it's time to "let sick employees stay home"!

(Yes, I went to work today even though I was sick! Thanks for asking. :-)

Technical Debt

Technical debt is a great term, originally coined by Ward Cunningham, to convey the reality of future problems brought about by making decisions with an eye to short-term gains instead of long-term correctness. This is not a new concept, but before Ward, it had never been applied to software development. (Martin Fowler reports that the term was used in Ward's report at the OOPSLA conference in 1992.) Let's say that again incase you missed it.

Technical Debt: future problems brought about by making decisions with an eye to short-term gains instead of long-term correctness.

This exact concept was used years ago in the advertisements for Fram motor oil filters. Every car owner knows that they need to replace the oil and filter in their car on a regular basis or they will eventually experience engine problems. The advertisements in question stated that using inferior oil filters (naturally, anything that wasn't sold under the Fram brand name) would eventually cause the same problems. At the end of the commercial the mechanic looks at the camera and invites you to "pay me now or pay me later". This is how you avoid mechanical debt; take small amounts of appropriate action now, or take massive (and expensive) reparative actions later.

The financial world has had this concept from the beginning of money (or at least the lending thereof). Debt is a very real thing for many people and it's something that gets dramatically worse the more you fail to address it. The definition of worse can vary of course. For some "worse" means having a credit card declined, or a car repossessed, or a house repossessed, or a business declared insolvent. And then there are some who operate outside of the realm of the legal, who will be more than happy to break your kneecaps when your debt exceeds the agreed repayment amounts.

One aspect that most forms of debt share is the personal pain (sometimes literal pain if you borrow from stereotypical Italian gentlemen named Vinny) from failing to address that debt. When you ignore it long enough it has a way of getting your attention, often to the exclusion of everything else. While this is generally quite unpleasant, it does effectively concentrate the mind on efforts to bear down on the debt and start making it go away.

A big problem with technical debt is that the personal pain is often not applied to the one making the decisions and who, by all rights, should be experiencing it. I'm talking about Information Technology managers here. While not a few bad decisions are made by programmers, the clear and massive majority of them are made by managers. The problems and pain of the technical debt is then felt by the programmers. The irony in the situation is that those same programmers have likely warned against exactly the situation that they now find themselves placed in.

I have seen technical debt accrued in almost every company that I have worked for. There seems to be a slavish adherence to the concept of "first mover advantage". This would be lovely if the concept worked, but the general public seems to be learning to place a premium on correct over fast. Sadly, the memo hasn't made it to Information Technology management yet. Consider Microsoft's Vista operating system. I understand from reading technology blogs that Vista was released because they were fed up of the computer press asking when it was going to be ready (Really, what's the rush? Doesn't everyone take five or six years to release a new operating system version?). Microsoft picked a date and shipped it "no matter what". The result was a stack of bugs tenuously piled up into the shape of an operating system.

I'm sure some are reading this and saying words to the effect of "but you have to spend money to make money", meaning you have to accrue some debt to make money. I call "nonsense" on that. The only way to get out of debt is to spend less than you earn. It also happens to be the only reliable way to not get into debt in the first place.

Technical debt is completely avoidable. You can run your project in a debt free fashion. I've done it and thereby feel that I have the right to refuse to hear that it's impossible. The trick is knowing what's right, sticking to your guns and doing it. Lather, rinse, repeat; as the shampoo instructions say.

WHEN IT'S DONE

A good example of running a technical project debt free may be had by watching almost any open-source project run by the Apache Software Foundation. The Apache folks have a reputation for high quality work. Part of this comes from the natural tendency of good programmers to want to work on Apache projects. Another part of the quality equation comes from the peer review that naturally happens in an open-source project where everyone can see all of the code and is free to examine and comment on it. The biggest part of the reason for the quality of the Apache projects comes from their standard answer to the most common question received on their mailing lists.

The most common question that I remember seeing when I frequented the Apache Struts mailing list was "when will it be done?" A few months after any release I remember seeing this question being asked about the next version or point release. As regular as clockwork this question would come up time and time again. The impressive thing was that the answer was always the same. The answer was always "when it's done!"

Even a superficial consideration of the question leads to the conclusion that it's the only answer that can realistically be given. If a project team sets out to perform a certain unit of work, then they either perform it or they don't. It's a binary issue and that unit of work is delivered or it isn't. While I understand that life brings surprises and plans can change, the work is still either done or it isn't. Sometimes those life surprises are bigger than expected and the plans have to change and the unit of work is modified and that will affect the estimated completion date (remember, an estimate is only a wild guess in a suit) because the work is still done when it's finished. Even changing scope does not eliminate the binary nature of the matter.

All Apache projects are done when they're done. Period. Apache projects carry a heavy expectation of excellence. I know that even back in the 1.0 days of the Struts web framework, I was able to rely upon it totally for the system that I was the tech lead over. In fact we even went to production with a beta version of Struts 1.1 as the quality was so high that I couldn't see any reason not to use it while I waited for the final 1.1 release.

The Apache projects know what the right thing is and they stick to their guns. They know that they pick a unit of work to perform. They work on it until it is finished to their satisfaction and only then do they release it to the waiting world.

Sadly, the concept of "it's done when it's done" is foreign to the modern Information Technology manager. Modern Information Technology projects are all driven by deadlines; arbitrary deadlines at that. I'm working on just such a project now, fixing a compliance issue with our widget sales. We're already out of compliance, but the management thinking was that it should be fixed by the end of the year so that we'd be compliant next year. There was no examination of whether that was doable by a single developer still getting used to the system in question and for which there are no tests so who knows if anything gets broken? Management says proceed because it's more important to be seen to be fixing the issue even if it's a hurried fix that might in turn need to be fixed.

I don't think I could begin to count the number of timeframe driven decisions that I have witnessed or have heard details of from reliable sources that I trust. These decisions have a long history of turning out badly, but because the pain is felt by the programmers, the managers find them most agreeable.

This is root cause of technical debt. Information Technology management making bad decisions based on a desire to get things done "at the speed of business" and then not feeling any of the follow-up pain of those decisions. And the punditry wonder why there are falling numbers of programmers. I know that I've advised my little geeklets to not even think of working in Corporate America and especially not Information Technology. Even just last week I was chatting with co-workers about Corporate Escape Routes; just how do we tunnel out of the cubes that are our prison cells?

So, how does a deadline driven approach to project management, the way that it's implemented in Corporate America today, cause technical debt?

Let me start by saying that deadlines aren't all bad, especially if they are determined by a careful examination of the amount of work that needs to be done and the availability of skilled programmers to do it. This is not how it's done in Corporate America today, so we'll skip straight to discussing "pick any two".

PICK ANY TWO

Information Technology is still a relatively new discipline, but it has been around long enough to have had classic project management principles applied to it. These principles tell us that there are three aspects to a project and that two can be tightly controlled at any time with the third varying depending upon the decisions you make on the two you choose to fix.

The three aspects of an Information Technology project are Scope, Time and Quality. Some people use the term Cost instead of Time, but Cost tends to vary in direct proportion to Time, so with the time obsession of Corporate America, it seems more appropriate to call that aspect Time. The interplay of these aspects are seen by way of tradeoffs. The more rigidly you fix any two of the aspects, the more the third one is left to vary.

A good example of an engineering tradeoff would be NASA. These folks put people into space and bring them back again alive and well. NASA fix Quality at it's maximum and Scope doesn't change because otherwise there's no point in the mission. This leaves Time/Cost as the variable. Of course, being a government agency, it seems like Time/Cost is the last thing they worry about anyway!

Now, in most Information Technology projects, and when I say most I mean every one that I've been on and just about everyone I've heard of from my contacts, the two fixed aspects are Time and Scope. As a motivational speaker that I heard many years ago said, "Every project starts out with a deadline and a name."

Even the Scope is not usually that well defined. Hence the large number of incidents of scope creep. It's not really scope creep ... it's more that the project was started before they knew what they wanted. This is the usual behavior of Information Technology management. They aren't sure what they want, but they're deadly certain about when they want it. To get a change in the planned project completion date usually requires a presidential declaration, delivered by pink pigs flying in formation with white unicorns.

This is why it's so dangerous to offer estimates to managers, because once they've heard a date inside the timeframe they wanted to hear, they stick to it like the proverbial limpet. I know that I've offered estimates to managers and have had the number halved right in front of me. Usually they say something to the effect that they had to do that as their manager wouldn't accept an estimate that large.

So with the Time aspect being cast in concrete and the Scope staying still at best and increasing under normal conditions, the only other aspect left that can vary is Quality. And the universal observation is that Quality will always very downwards. This fits with the law of conservation of energy. If Time is fixed and Scope tends to increase, then the only direction that Quality can go is down.

This concept does not seem to fit with the worldview of the average Information Technology manager. Funnily enough, everyone else seems to get it. I particularly like the way that the U.S. Navy SEALS express it: "Fast is slow. Slow is fast." When everything is melting down around you and you need something done right, then slow down, deliberately slow down and concentrate on doing the action slowly and correctly the way you would have done it in training and let the muscle memory take over. It will be done right (for whatever your definition of "it" is).

Information Technology managers are the reverse of the SEALS. When a problem occurs they switch into panic mode. Everyone is expected to stay late. Senior managers tend to start hovering outside the cubicles of those performing the fixes. Hourly status meetings get called and are conducted in stand-up fashion outside the fixer's cube.

BON APPETITE

I'm going to wrap up with an example currently being worked on by others while I relax at my local Starbucks and enjoy a cup of coffee. The core pricing module for our widgets is broken for the introduction of a new widget. It is blowing up when pricing is requested for that widget. I'm in the process of coming up to speed on this module myself and so I know that there are zero unit tests in the code base. I have written tests for all of the code in the area that I'm working on, but these have not been promoted into the main code base yet. The lack of unit tests means that there are no areas that can be considered as bug free. So the bug could be anywhere. (Where there are good unit tests, there can be no bugs!)

It would seem that the problem involves a NullPointerError, so the chances are good that some domain object is being incorrectly initialized. Unfortunately no one knows which one it is because none of our domain objects have any kind of guard conditions for their input values. Any of our domain objects can be in any condition. There are no guarantees that they are ever in a valid state.

The decisions to have no tests and no guard conditions to force data integrity are the result of previous bad decisions motivated by the desire to get stuff done quickly. These decisions have consequences, we know these as Technical Debt, and those consequences have grown large teeth and claws and have developed a taste for untested code. In this core pricing module the untested code stretches as far as the eye can see.

Bon Appetite Mr. Consequence!

Employee Reviews

As a pastor and the editor of our district's newsletter, I have always been used to having to report on what's happening and how my team is performing.

Being the editor of the district newsletter this responsibility includes reporting before the full district board and the district superintendent each fall during the district planning session.

While it might sound intimidating reporting to the Bishop, it's really not a huge deal as I stay in contact with my representatives throughout the year and make sure that I know what we all did, why we did it and what we are planning to do in the year to come.

It's not much different at church board meetings. I meet with the church board roughly every quarter and we discuss the state of the church, finances and direction. I consider it part of my job to know what is going on in every part of the church, who is doing it, why they're doing it and how it's going.

Then at work I find that the process for end of year reviews is totally messed up. This is not just a slam on my current employer. I have found this to be the case almost everywhere that I have worked for going on twenty years. The whole approach that Corporate America takes is fundamentally broken.

Part of the reason for this is that Corporate America is full of managers instead of leaders. That's a rant for another day, so I'll move on to the rest of the reason. The big part of why end of year reviews are so broken is that managers don't know what people are doing because they get themselves so overloaded with anything other than interacting with their direct reports.

The funny thing about that, is that many Human Resource departments even have rules in place to limit the number of direct reports that a manager has, to ensure that they are not overloaded to the extent that they can't track their direct reports. At my current employer, I believe that the maximum number of direct reports is in the region of a dozen.

Everything is in place for the manager today to know what their people are doing. Yet they don't. I just talked to my manager yesterday for the first time in months about what I'm currently doing and that was only because I bumped into him in the bathroom. Now, my manager's a nice guy and I have nothing personal against him, but I'm pretty sure that's not how the Human Resources department thinks that information flows in the corporation.

As I've spoken of before, the size of the congregation that I pastor is in the low thirties. I can tell you how they're all doing. I see these folks once or twice a week for a few hours at a time, yet I know more about my congregation than most managers know about their direct reports who come to work five days a week for a minimum of eight hours a day. Does this strike anyone as odd? I think it's disgraceful.

I know which ones of the congregation are undergoing medical treatment and have visited a number of them (or their spouses) at the local hospitals. I know which ones are struggling with issues and what the issues are. I know which ones are trustworthy when it comes time to ask for tasks to be done. I know which ones with kids are in charge and which ones let themselves be walked all over by their kids. I know which of our men wear the pants at home and which ones have abdicated the family leadership to their wives. I know who works in which industries and how their jobs are going. I know who is happy at work and who isn't. I know who is praying regularly and who is tithing regularly. I don't do this to pry. As far as I am concerned, this is just part of the job. You cannot lead someone or minister to them if you don't know them.

But it gets better. Almost everywhere I have worked, the end of year review process involves the direct report filling out a self-assessment review in which they write what they've been doing and rate themselves on how they've done with their projects. The big giveaway is that when the manager hands out the end of year review, that it bears an uncanny resemblance to the self-assessment that the direct report handed in.

Did I say "uncanny resemblance"? How about when you get your evaluation and the manager has copied and pasted your text into their document changing "I" to "You". Perhaps I'm alone on this, but I find that uninspiring and unimpressive.

May I kindly suggest to any manager who can't give an on-the-spot report of how their direct reports are doing that you are obviously not managing. I don't know what you are doing (and it's likely that your staff don't know either), but you are not managing. Please, either start managing, or ask for a different job title and have your direct reports transfered to someone who is prepared to put in the effort to know what they're doing!

Who moved my bliss?

Far too many years ago, as a young computer enthusiast I thought to myself that it must be wonderful to be paid to write programs. After all, I wrote them at home, for myself, for free, so the idea that someone would pay me to do that for them seemed somehow magical to this teenager. So I diligently applied myself to the art of creating computer programs, got a degree and headed for the big city to ply my new trade.

Ah, yes, the optimism of youth. Silly me! There is no joy in corporate software development. None. Not even a little bit. The reasons for this are numerous, but a couple of recent blog posts highlight a few of the reasons nicely:

I don't understand computers is not an excuse

and

I quit my job today

I'm sure I'll get around to listing a few more here in the coming days, especially after my experience with our company architect yesterday. My last few dregs of remaining hope for Corporate America pretty much shriveled up and died on Friday afternoon.

Green Shift

Reg Braithwaite over at raganwald has a great post about Green Shift. What is Green Shift? Well, it's a term coined by Scott Ambler (back in 2006 writing for DDJ) for a wide-spread corporate anti-pattern. The pattern does like this:

Nobody likes to report bad news to the layer above them, so managers (it's usually managers, most programmers are brutally honest) take the reports they are given and spin them positively. Repeat this for a few layers and a massive compound interest of spin will accumulate until the report that reaches the highest level has no similarity to the reality being reported on.

The reason that it's called green shift is from the "traffic light reports" that modern project management likes to employ for their reports to senior executives. Green means everything is good, yellow means there are issues to be addressed and red means serious problems. If the programmers on a team report problems, that should turn the report red for that project. This would reflect badly on the project manager, so they will often report it as yellow with a written note that they are confident that the current batch of issues will be addressed successfully in the near future. See how this is close to the truth, just with a very positive "glass half full" kind of perspective? The problem is that this is now a subjective rather than objective report. The next layer will take this report and take the project managers expectations and read them as cast-iron guarantees that the problems will be solved before the project is delivered. This layer will then pass on their report with the project status as green, because they believe that everything will come in fine at the end and that there is nothing that senior management needs to worry about. Again, they feel that they haven't lied, but have just taken a positive view of the report they received.

The more layers there are between the programmers and the CIO, the worse the effect gets. Unfortunately, this is a very common occurrence within Corporate America. I have seen this everywhere that I've worked and it seems to be getting worse.

This may come as a surprise to many programmers who think that it's only IS managers who suffer from this form of insanity, but it is in fact so widespread that there are classic Internet jokes about it:

In the beginning was the Plan.
And then came the Assumptions.
And the Assumptions were without form.
And the Plan was without substance.
And darkness was upon the face of the Workers.
And they spoke among themselves, saying, "It is a crock of sh-t, and it stinkith"
And the Workers went unto their Supervisors and said, "It is a pail of dung, and we cannot abide the smell."
And the Supervisors went unto their Managers, saying "It is a container of excrement, and it is very strong, such that none may abide by it."
And the Managers went unto their Directors, saying, "It is a vessel of fertilizer and none may abide its strength."
And the Directors spoke among themselves, saying to one another, "It contains that which aids plant growth, and it is very strong."
And the Directors went to the Vice Presidents, saying unto them, "It promotes growth, and it is very powerful."
And the Vice Presidents went to the President, saying unto him, "This new plan will actively promote the growth and vigor of the company with powerful effects"
And the President looked upon the Plan and saw that it was good.
And the Plan became Policy.
And that, my friends, is how sh-t happens.

[A tip of the hat to the Jewish Humor and Joke Page]