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.
Friday, August 09, 2013
Monday, August 05, 2013
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
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
Monday, July 22, 2013
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.
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.
Saturday, July 20, 2013
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
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
Tuesday, June 25, 2013
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
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
Sunday, March 31, 2013
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.
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.
Friday, March 01, 2013
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.
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.
Subscribe to:
Posts (Atom)