The Paradox of the Human Condition

I'm going to wax a bit philosophical here, in contrast to my usual technocentric rants, so bear with me.

I was struck with a realization yesterday that the two traits that allow us humans to do such great things are the same traits that allow us to do such horrible things.

The first trait is the ability to sublimate our personal needs to that of a grater cause.  This leads us to do such things as give up a comfortable life to travel to an undeveloped land and help the local people improve their condition; to fight against injustice in the face of personal attacks; to jump onto a grenade to save our comrades.  We can identify with a cause larger than our own lives, and work towards furthering that cause at the expense of our own well-being.
But is also leads us to harm those who do not share our history; to pilot planes into buildings; to attempt to eliminate entire peoples because they are different.  It is the adoption of an greater goal that removes our sense of kinship to the rest of humanity.

Conversely, the second trait is that selfishness that drives us to excel at collecting wealth that can be used to do great good.  The billionaires that fund disease-eradication efforts, or publicize tragedies in far-off countries; the driven individuals that want to build rockets, or non-polluting cars - they expect to get rich from it, along the way.

But this leads to the seduction of power.  Once one has enough money, one becomes accustomed to using that money to influence the rest of the world, and then that distorts the political process in the local governments - either directly through bribery and outright force, or via indirect means - funding 'policy groups' and industry councils that present an individual's view as a public opinion or social good.  Soon any deviation of society from the personal preferences is decried as a bad thing.

So we must learn to walk the middle way, somehow, avoiding the extremes of selflessness and of selfishness, and tempering our personal view with that of society's.

The Red Queen Problem in Software Development

I was listening to one of The Job's internal meetings the other day, and the CEO was talking about how we needed to do things better and faster than ever.  I got angry, because this is exactly the thing that is screwing up everything in the tech industry - nobody wants to do the right thing, because that would take longer and might allow some other company to actually be the first with a crappy product in that niche.

Then I read Drew Crawford's "Of Wizards and Magical Machines", and damned if he didn't capture some of the things I wanted to say here.

Software has come to be seen as something easily changed, taking no time to alter and configure.  Management thinks that a bar napkin counts as requirements, and there is no need for clarification or details - we can pull those out of thin air and it's the developers' fault if the guesses are wrong.

(I have a paranoid theory that software company management hates the developers because development is the only phase of the software life-cycle that cannot be skipped, and we developers continually whine that we need more time to create the castles in the sky that they think up)

But we can't always be faster - the problem takes a finite amount of time to understand, and another finite amount of time to analyze, and only then can we start to develop it correctly.  No amount of Agile process will remove that time.

Bug-Ception

It amazes me that people writing bug-tracking systems never seem to find all the right points to track.

At The Job, the one we have was written under the (apparent) assumption that nobody ever has more than 1 release stream, where a bug might be present in both streams, and need to be tracked as the same bug, but with different fixes (either due to schedules for the releases, or for differing code in the streams)

So we get a mess of duplicated bugs because each tester thinks of a different way to describe the bug, and can't search for the kindred bug, since it will have a different ID in the other streams

Then the process geeks came along and decided that we could keep all the releases under one bug.  Of course, that leads to total confusion about if it's been fixed in any specific stream.

Here's a tip

When you are writing a set of methods for something where you want to get the stuff compiling, but you are not looking to do full TDD, because you are worried you will forget something, then just put assert(False) in the bodies of the methods, to make sure that they will stop the system if they are run before you have the code in them.

Languages that don't have assert() can use something else - a macro that calls exit().

All you want is something that will stop things dead if you forget to fill it in.  This is better than log message or output, because you can't forget to make it work

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