The Long Dark Night of the (Professional) Soul

I had a somewhat upsetting epiphany today.

Over the past couple of years, I've had the chance to take a number of job-provided training.  Some of it was mandated by The Job, and some was my choice.  In that time, I've noticed that even though I don't mind the classes in some cases and in others actually really *like* the class, I spend the days before and after in something akin to dread.  It creeps up on me and lingers around the time I take the class.

Today I realized what it was.

It's the awareness that I can't use the stuff I'm learning to improve my code, because The Job won't let me.

The Job has tight restrictions on the number, size, and type of code changes that can be made to released products.  Almost all of the things that need to be done to the code are non-trivial changes of infrastructure, medium to large refactorings, additions of many unit tests, etc.  All of which require Change Notices, which need approval for altering code that gets released to the customers.  And all of which will not pass the current standards, which basically are "Is some customer aware of it, and complaining about it?"

So I sit in class learning many new and wonderful things, and never get to use them in my main coding space.  And it makes me unhappy.

It's Hard to Soar With The Eagles When You Are Surrounded By Turkeys

Some days you just can't win.

After a hectic week, I can definitely say that one of the big demotivators I've run across is the dismissive attitude you sometimes find in quasi-competing groups.  I found out that one such group has been making interface changes and not passing the info back to my group because it was their fervent belief that we would be deprecated Real Soon Now, and our product would never need to connect over the modified interface.  This despite having at least 2 prior cases where that belief was proven false, and I had to make sudden adjustments to my product to cover for their omissions.  

It is poisonous to morale, this empire building mentality.

Don't let that behavior go on at your company

Optional, Expected, Mandatory

Hello again!

Today I got reminded that not matter what anyone tells you, there is no such thing as a temporary feature.  Once you've added it to your system, even as a hidden setting, your support staff will talk about it, and soon customers will ask about it, and it's not long until someone depends on it, and after that, you're getting enhancement requests for it.

So when you are writing the code for that kludge that one collaborator needs just to get things past integration testing, you need to think like this will be a fully-supported, documented feature, because it soon will be.

Don't use an environment variable when you have a database.  If you can't add it to your database immediately, write the code to make it easy to convert when you do get a chance to change the schema.

Don't expect it to be ok to set this once at process start and never re-read the value until the next restart.

Don't slip the code change into a side branch of execution that suits just that one customer/collaborator/installation.

Do write a Change Request to fix the kludgy nature of this in the immediate next release

Invisible Pains

This past week, I ran into a situation that I have seen in the past, but never quite grokked fully.

At The Job, the tech support organization is fairly savvy in the ways of computers, so they have a good number of programs and scripts they use to gather data on issues, fix known problems, etc.  What happened was that there was a customer experiencing a problem, and Tech Support had written a script that fixed that problem, running nightly.  The customer was happy.

What caused the problem was that Tech Support did not come back to development and let us know that there was a problem ongoing that they were covering for.  So the problem festered, and now we have a deadline and a problem that we do not have time to fix and run through our QA process in time.

So when you are talking to your Tech Support people, be sure to ask them if there are any ongoing issues that they are handling that might be fixable in the product code, so tha you can solve them before they become big issues.  The Tech Support people usually love to be the fixers, but they sometimes let that override their duty to report things up the line to get real fixes.

Something Sure Is Rank

Recently I ran across a few articles discussing the not-uncommon corporate HR practice of stack ranking.  Frankly, my jaw dropped when I read that that practice has a lot of traction in the corporate world.  The premise is so flawed that I cannot believe so many people swear by it.

For those not familiar, stack ranking is the practice of ranking a set of employees in a linear fashion, from worst to best, and then marking the top 20% as excellent, the middle 70% as adequate, and te bottom 10% as failures, and suitable for dismissal.  It assumes that the population follows the familiar bell curve.

So let's take a look at the problems with this.  First the technical ones

1) Sample Size
The bell curve ( or normal curve) is the expected distribution is valid only for sufficiently large populations.  Most workgroups are not nearly large enough that they would match the normal curve in the distribution of ability.  Use of stack ranking on small groups can incorrectly mark people of lesser ability as part of the bottom 10%.

2) Random Selection
The normal curve also assumes that there is no skewing influence on the population.  Most companies proclaim that they are selective in their hiring, so they should not have any poor performers.  Moreover, if the company has run any rounds of performance-based layoffs, the population of employees is no longer normally distributed.  Once you remove the lower 10% of the population, there is no longer a "lowest 10%" to choose from.

And now the social reasons against stack rank:
3) Arbitrariness
Since most people are aware of the basic fact that statistics requires large groups of people, they know that in a small group there can't be a bottom 10%.  So when one of them has to be sacrificed as the goat, they begin to see all the rankings are either arbitrary or bogus, so they become cynical as to the merit of the evaluations

4) Gaming the system
Once employees know that they are ranked against each other and avoiding being in the "bottom 10%" is vital, they will start to alter their behavior to try and avoid being the low man.  This leads to anti-social activities such as information hoarding, sabotage, and grandstanding.  They stop trying to further the group goals in favor of their own.

Given all this, I cannot understand why this is favored by corporate management except as a means to instill fear in the employees and enable the rewarding of those liked by the managers.

Getting Input, But Not The Wrong Kind

One of the things that I noticed a while back is that quite often it seems impossible to get others to provide their input to a design or document.  Nobody wants to respond to your questions, or doesn't have the time, etc.

So I started presenting every document or design as a strawman - I made sure to put in things that I thought good but controversial into every section.  Then I sent it out for review as version 0.1.

The controversial ideas would galvanize the reviewers to respond with their better ideas.  It seems that while few will stick their necks out to propose solutions, almost everyone is comfortable with criticizing someone else's solution.  It seems to allow everyone to assume their preferred role in the organization - wise sage, gadfly, elder statesman, or just plain old curmudgeon - without risk.  It's not their idea that's being looked at, and if their input is ignored, they are free from blame, but if the idea is a success, they contributed to the discussion, and therefore helped bring it to market!

Curiously, there is a counterpoint to this situation - sometimes you have a manager/PM/customer who cannot allow a document to pass by without making some changes.  I'm not the only one to notice this, not by far.  And the solution is exactly as described - make some very specific things either wrong or superfluous, and let the manager/PM/customer tell you to change them. 

A corollary to this happened to me at my first job.  We had a group of senior customer executives visiting to see our initial demo of the product.  We showed them what we had - a mockup running on a terminal, and then they were shown the various other bit s of technology that were being assembled into the final product.  Now, this product had some very specific color-coding of icons on the UI, and we were already planning on making the color specifications loadable from a configuration, to allow for the differences in the color monitors of that time, yet we had the whole group of executives staring at a screensaver trying to point out some specific colors that specific icons needed to be.  It was something that was best dealt with in a document, but they felt the need to impress us (or each other) with their acumen at determining between close shades of magenta.

False Urgencies

Recently, The Job has offered me a number of occasions where the usual software development process of asking for an estimate has been skipped entirely,  Several times, the Manager is sending out an email announcing the next code freeze in 2 days, with a list of unfinished bug reports.  So there is a sudden scramble to finish things that night well be too much to finish in the remaining time.

This rant about bogus deadlines addresses this issue.  One of the tenets of good software is that is takes some time, and it is at least somewhat a creative endeavor.  So rushing your developers just to meet an arbitrary deadline is counterproductive.

Give them room.  Provide the list of desired changes, get estimates, and then juggle the schedule or the list to fit.

Oh, and never think that twice-daily, 2+hour progress meetings with VPs, EVPs, and the rest of the C-level wannabees are going to help.  Nothing ruins concentration more than knowing that in 3 hours you are going to have to explain why you haven't made "satisfactory" progress solving a problem, where "satisfactory" means "saving my division customer satisfaction rating so I get my 35% bonus" for the EVP