Nobody expects the Spanish Inquisition!

Oracle Corporation (a purveyor of wickedly expensive databases) purchased Sun Microsystems last year. Sun was the creator of the Java (a highly trademarked) programming language and environment. There were concerns voiced at the thought of Oracle Corporation (also known as the keep buying Larry more ocean-going racing yachts club) owning Java (oodles of trademarks) as they are known for being more interested in making money than running open-source projects or loving up on programmers. These thoughts were usually swiftly hushed and everyone was told that it would all be fine and that as the crown jewels of Oracle's (aforementioned large and heavily lawyered corporation) offerings were all deeply tied to Java (did I mention the trademarks?), there was no way that they would do anything stupid. After all, they said, you don't get to afford trans-Atlantic racing yachts and Gulfstream jets without number unless you know something good about business. So the geeks switched to silent waiting mode.

Lately, there have been quite a few cracks in the facade of Oracle (so big, they make Big Brother look like little sister) as benevolent curator of the Java (way more trademarks than you'll ever have) language and brand. I'll try to keep myself to the two latest examples and then deliver the pithy conclusion.

The Apache Software Foundation (these are the good guys) is a member of the Java (trademarks, trademarks, trademarks) Community Process, the overseeing body charged with guiding the ongoing development of Java (err ... trademarks). Well, they happen to have a project to re-write the Java (trademarks and then some) standard libraries in a cleanroom manner, so they can be used freely and under the business friendly Apache license. All good stuff and Sun (may it rest in peace) had an agreement with them to release the Technology Compatibility Kit (TCK) under a suitable license for the Apache project to use so they could validate their implementation the for Java (trademarks, come and get 'em) standard libraries.

Unfortunately Sun (formerly great networking company) never got around to honoring this arrangement before they mis-managed themselves into the ground. Oracle (dark ominous music plays here) were previously in favor of this arrangement, but now that they own Java (and all the assorted trademarks) they have suddenly gone bi-polar on us and no longer think this is the swell idea it used to be.

This is a big deal, because while Java (marks of tradiness) is now GPL (all hail Richard Stallman) and the replacement libraries are open-source (a shout-out to ESR), there is the slight problem that nothing is allowed to be legally called Java (with or without trademarks) until it has passed the TCK. And Apache can't use the TCK because of one crazy legal clause in the whole arrangement.

Hudson is continuous integration server software. It is hosted on the java.net facility which is now owned by Oracle (not actually evil, but they make Microsoft look cuddly) and even worse, it would seem that Oracle (who should borrow Google's don't be evil mantra) own the trademark or copyright or copymark on the name Hudson. And one of their VP's wrote a snotty email explaining that folks were welcome to fork the project, but they couldn't have the project name.

There is great principle that I normally apply in such situations: "Never ascribe to malice what can adequately be explained by incompetence!" And I think it might be useful here. At this point, I am not ready to accuse Oracle (you get the picture) of trying to kill Java (mark that trade), but I am quite certain that there are no signs that they aren't!

The title of this post come of course from that classic Monty Python sketch about the incompetent inquisitors of the Spanish Inquisition.

One week, one character

Tracked down a tricky error over the past week. No, I'm not that slow, but I had to get a whole new database sandbox created and populated and then fix my data source definition before I could even get to the point of investigating the problem. Once, the data was flowing into the program, I discovered that I had a broken domain object. I had had trouble getting anyone to be excited about me retro-fitting unit tests into the web application that I'm porting from WebSphere to JBoss and so I'd done a few (about three dozen) of what I thought were the main objects. Wouldn't you know that one of the ones not tested had an error in it! At my hourly billing rate, that's several thousand dollars tracking a problem that would not have existed if I had been free to unit test all of the domain objects. The fix? A single exclamation mark to reverse a wrong boolean statement.

Just Tell Me What You Are

In these wishy-washy days, people don't seem to be keen to be defined by what they are, but prefer to be known for what they aren't. I got to thinking about this on the way home from the in-laws today as I drove past a large'ish Seventh Day Adventist church building. Now, I'm sure they have things they stand for, but mostly they're known as the folks who think that we're wrong for having church on Sundays and that we should celebrate on Saturdays like they do. Hmmm.

Let no man therefore judge you in meat, or in drink, or in respect of an holyday, or of the new moon, or of the sabbath days:
Colossians 2:16 [KJV]

The Seventh Day Adventists are not wrong for having church on Saturdays, but nor are we for choosing Sundays.

And for those who like a little more politics in their reading material, we can make similar observations about President Obama and especially so of his advocates. A large part of the campaign approach of then candidate Obama centered around the point that he wasn't Hilary Clinton and then even more emphatically that he wasn't George W. Bush. And pretty much that was it. Oh sure, he made promises and expressed opinions, but all politicians do that. It just strikes me that being the un-Bush is a pretty weak platform to run on. (It did get him the Nobel Peace Prize, for what that's worth these days!)

Set the bar too high?

So there I am at the fellowship after oldest geeklet's piano recital and I was going through the line for snacks (Mmmm ... snacks!) when I overheard just a snippit of the conversation between piano instructor's husband and some other parent.

Other parent was complaining that people (I assume he meant us evil conservatives) were alledging that President Obama was setting the bar too high. Don't know which bar.

Piano instructor's husband replied, to the effect of "well, why not set the bar high?"

I was under strict instructions to be on my best behavior (even had to take my NRA cap off at the recital), so I refrained from joining the conversation and pointing out that when President Obama even seems to know where the bar is, that he has trouble clearing it on the lowest settings!

It really sucks having a president who still needs training wheels for his leadership role.

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. :-)

No, no and thrice no!

Over at Coding Horror, Jeff Atwood has run off the rails and gone over to the dark side. He has uttered words that are indistinguishable from those that come forth from the majority of Corporate America Information Technology management. Don't believe it? Check it out for yourselves. I'll be waiting for you when you've read it.

http://www.codinghorror.com/blog/archives/001160.html

Not being one to beat about the bush, let me offer this comment to Jeff's idea.

No, no and thrice no!

Since pastors aren't supposed to say naughty words, I am left with little alternative but to fire up some sarcasm and get to it.

There are so many things wrong with this perspective that it's almost impossible to know where to start debunking this foolish notion. After all, if quantity was all that mattered, then the Microsoft Vista operating system would be the best thing since sliced bread, the bee's knees and the cream of the crop all mixed in together and served with a cherry on top. Last I heard, it was seven shades of dreadful. (Or at least that's what I hear, I use Mac's at home and my employer hasn't moved past Windows XP yet.)

I've mentioned this before in this blog, but the system that I and my co-workers are trying to fix, is an eight year accretion of code. If quantity trumps quality then how come I can't find any in the system? There isn't any. I've looked. My co-workers have looked. And then because we hoped there was something of merit in there, we ran some automated code quality tests on the codebase and some of the modules on their own break the email system when the error logs are emailed internally. That's quite a lot of errors and not a lot of quality.

If quantity trumps quality, then how come the twelve line blank templated JavaDoc before each of the methods don't give me the warm fuzzies? It should. I mean, what's not to like about fifty percent of the source code in any randomly selected Java source file being empty JavaDoc? And broken JavaDoc with invalid JavaDoc tags at that. Goodness, I bet Jeff would love them. There's so many of them, I might ship him a few as we have so many of them to spare.

Now, don't get me wrong here, I think that the best way to learn to write code is to read a little theory and write a lot of code and throw it away. Then repeat. Read a little more theory and then write a bunch more code and throw it away again. Keep repeating this, as I have for about twenty eight years, and you'll be a fairly good programmer. It's not quantity of practice code that I object to, it's the inference that any code base can attain quality by just churning out code with no regard to quality.

Sorry. Ain't gonna happen!

You see, the ceramics example that Jeff gives us just proves that practice does help. There were items made by the "bulk" half of the class that were excellent, because the quest for quantity effectively forced the students to practice their craft. But the admission that not everything was of high quality shows the problem.

Any programming project is the sum of all the code that gets written for it.

By seeking quantity and taking a "quality be damned" approach, you may eventually have the quality that comes from practice, but that quality code will be on top of the early dross and a diamond in the mud, while still a diamond is still muddy and hard to appreciate.

So, may I suggest, as I have learned from experience, that quality comes from caring and practice and not as an accidental discovery within bulk code.

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!

Why project managers get no respect

I think that Scott Berkun comes close to understanding a fundamental truth of modern project management in his blog post about Why project managers get no respect. There's more to it than he suspects, but he gets high marks for realizing that, on average, the problem lies with the PMs rather than the programmers.

I have a good rant simmering on the mental back burner about project managers, but it'll take several more weeks (at least) until it's ready for posting. Stay tuned and watch this ASCII character 32.

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.

Project Managers

There are few things in this life that can instantly raise my blood pressure, but I.S. project managers can. While researching this Sunday's lesson, I re-discovered this scripture that I think perfectly captures my feelings about them.

Who is this that darkeneth counsel by words without knowledge?
Job 38:2

Nothing else to add.