Showing Initiative vs Being a Cowboy

A few weeks ago, I fixed a bug without being asked to do so. Shortly afterwards, I was asked “Why did you fix that bug? Who told you to do it?”  The question arrived in email, so I couldn’t be certain about the tone-of-voice, but I’m sure you read this sentence with the same tone-of-voice that I did.  You are imagining someone giving you a sour-look or maybe even a scowl.

If you were a smart-aleck, you could respond like you didn’t know it was a rhetorical question “I fixed the bug because it was a bug. That is what I do when I find a bug. I fix it. I’m pretty sure you don’t want me to do the opposite of that.” However, since you and I are very professional, I wouldn’t say something like that. Right?

When I’m asked a question like this, it does bother me a little. Mostly, because I know my own motivations. I am not a loose cannon and I don’t go around looking for trouble.  I also don’t typically invent assignments for myself.  So, when I find a problem and I fix it without being told, I know I am being proactive, a.k.a. “showing initiative”.  I don’t expect a pat-on-the-back, but I certainly don’t expect some reprimand or questioned about my reasoning or motivation.  This was some kind of misunderstanding, and it just needed to be worked-out.

Cowboy “Fixes”

I have worked with a few cowboys in my day. Those guys can be fun to work-with, but they can also cause some interesting problems.  Therefore, many companies have processes in-place to limit the damage that a cowboy could cause.  Most notably is controlling the dev and release process, to monitor and control what gets worked-on and included in any release.

Now don’t get me wrong. Not every action from a cowboy is a dangerous one.  A cowboy mostly does good work.  It is the dangerous stuff that really draws consternation and earns the cowboy his dubious title.  So how does a person tell when an action is “cowboy-ish” or not?

Here are the conditions when the action of a developer is cowboy-ish (or generally, overstepping a boundary, or outright dangerous):

  • Security reasons – an IT department needs a check-and-balance, especially when it comes to security. It is not appropriate for anyone to modify security settings/configs, without regulation.
  • Stability – it only takes once or twice, where you trusted someone to apply a fix, and they broke your production servers. After that, you tend to not trust anyone as much. If you are responsible for the system, then be proactive and assess any changes, before they are applied.
  • Cost/scheduling – Let’s face it, everything takes time and time equals money. Developers shouldn’t approve their own schedules, or purchases, beyond a reasonable limit.
  • Control – Management is there for a reason. They need to be informed about what is going-on. There needs to be a way to track this. Whatever you do to track your work, it needs to contain enough detail to keep everyone honest. People make mistakes. Everyone needs to stand behind their work and own their successes and failures equally.

It is pretty common to put processes in-place to limit people from fiddling with any of these topics. Only your most trusted people should have permission to work in these circles.  Even then, your most trusted people still have to follow a process and have some reasonable limits and checks in-place.

Cowboy Detectors / Monitors

Placing limitations or verbal measures in-front-of the cowboy is usually not effective.  A cowboy is inclined to get around boundaries and hurdles without notice (sometimes, just for the challenge).  The only safe way to enforce your process is to steadily assume that the cowboy will periodically test the boundaries.  The real defense here, is to monitor and test, often.

Lets just assume for a minute, that not-all developers are cowboys. In that case, when it is right to make a change/fix without being prompted?

  • Trust smart people – face it, if you trust your developers to modify code, then you should also trust their judgment elsewhere. If you can’t trust them, then review their work periodically.  Find the line between management and micromanagement so you have control, without getting wasteful. After all, the programmers may be some of the smartest people you know. Certainly they must be trainable. So train them, and trust them a little. If you need more communication, then focus on that, rather than pulling the rope tighter.
  • Bureaucracy becomes too restrictive – This is why the agile manifesto was written. Sometimes well-meaning people get carried away with creating processes to protect the company and people.  Sometimes you need a fix ASAP.  Define a process for doing something quickly.  Of course it should be the exception. So define rules for when it is acceptable.
  • For the right reasons – back to my initial statement: a bug is a bug. Once you’ve found a bug, it usually takes seconds to fix it. However, it could take minutes or even hours, to log and track a bug and its fix. A team needs to find an efficient balance between regulation and waste.

In the end, I worked it out with my supervisor.  She just wanted to be informed about every bug that I find and the nature of the bug. That way, she could track the testing of the bug and add it to the statistics that went to management.  It was a very reasonable request and I was glad to contribute to the improvement of our process.

Posted in IT Psychology, Professionalism | Tagged , , , | Leave a comment

Performance Testing – Do it / Don’t do it / It doesn’t matter

Performance testing is an awkward topic because it is usually very difficult to pin-down what you want / need. Honestly, everyone would really love it if every system could be blindingly fast.  I can’t tell you the number of projects / systems where that was the goal.  Whether that was achievable or not, is a different story.

A few months ago, I was asked a question about whether we should do performance testing on a project that was nearing completion. I had three answers pop into my head at the same time: 1) Absolutely yes, 2)  No, it is a distraction, 3) It doesn’t matter.  The person who posed the question was really hoping for a “yes”, but it wasn’t exactly that easy.

I would like to explain why each answer was correct.  Btw, this is applicable to nearly any project.

  1. Yes, we absolutely should do performance testing – Why not, after all, what have you got to lose. Do the test. It might show that everything is great, or it might reveal some kind of problem. At least you know where you stand.
  2. No, it is a distraction – Most projects have a primary directive like this: “complete these features, by this date”. With a few addendums like “oh, yeah, it also has to be bug free. That’s all. No, wait. It also has to be really fast, and secure, and following standards, and um, it probably should be supportable, and oh yeah, it must use contemporary technologies, and stuff”. If you re-read this charter statement, you will see that performance, is pretty far down on the list. Face it, if you don’t get the required features done by the due date, nothing else will matter. Keep your eyes on the prize. Plus, if you are an experienced programmer, you already have been using best-practices all-along. The system will already be running as fast as it can. Do you need a test to tell you that?
  3. It doesn’t matter – What do you really expect to learn from the test? “is the system fast enough?” So, what if it is not, then what? You will either choose to optimize the system, or just learn to live with it. However, if the system was made by experienced people, you are probably already getting maximum performance from the system. You will only be able to optimize it, if you made some mistakes along the way. Otherwise, you are not going to be able to squeeze much more power from the system, without rewriting portions of it. If your system was not written by experienced developers, then you might-as-well count on doing some optimizations anyway.

The point is this: The system is either fast enough or it isn’t. So, optimize the system or don’t.  But keep in mind that none of it really matters until you hit your deadline and feature set.  The fastest system in the world isn’t worth jack, if it doesn’t do anything.

Posted in Optimization | Tagged , , , , | Leave a comment

Project hand-off, here you go

Maybe if you work in a big-enough company, you’ve experienced the thrill of being handed someone else’s program. Not only did someone else write it, you probably didn’t have any say in how it was written. Maybe the author(s) were co-workers, or maybe it was written by some software dev company.  Either way, they are done and now the project is yours.  “Hey fella, somebody is taking over this project, and that person is you.  Have a nice day”.

You’ve heard the saying, “if you want something done right, do it yourself”. So therefore, if someone else wrote your program.  It will be.. um… you-know-what.

So now, for your entertainment, I would like to describe the process for becoming the owner of someone-else’s project

  1. You are informed that this project will become yours. You are initially excited, until you recall how this sort of thing goes, or someone else regales you with a horror story about a bad project hand-off. Then you hunker down and wait with trepidation.
  2. The project arrives. You want to know everything about the project immediately. You ask questions and don’t get the answers that you expect, or you keep hearing “read the docs”.
  3. You read the docs and they don’t contain the info that you want to see. You don’t really like the format. Who the heck wrote these docs in the first place? You are somewhat exasperated.
  4. You start reading the code and think
    1. This is organized in an odd manner. Wait, this-is-that, and that-is-this. I see now. I guess it is not that bad. Except for this thing and this and this. (repeat)
    2. It doesn’t contain all of the things that you think are most important in a project. However, it does contain a lot of things that you think are unimportant.
    3. As you dig, you find much of the project is written well, but quickly forget, as soon as you notice something that seems amiss. You mentally catalog all of the oddities.
  5. You complain to your coworkers about the oddities. They respond by joining-in and complain about their findings (only the bad ones). You think to yourself, “Wow, this will take a lot of work to overcome these obstacles.”
  6. You go to your boss and report that the project is a mess.
  7. You ask if you can throw the whole thing out and start over. Management says “no way”.
  8. You are a bit put-off by the insensitivity of management. You were really hoping they would say “yes, of course” this time. When will they ever learn?!
  9. After you stop wallowing in your own negativity, you organize your thoughts and determine where to get started in cleaning things up.
  10. You make some progress. Occasionally, you start refactoring things that are just too big and you have to undo your changes. This turns into a recurring task: make progress, make progress, get carried away, undo, make a better choice, and more progress occurs.
  11. Each time your refactoring goes astray, you check with your boss, if he has wavered in his resolve to retain this stuff. “It would be better if you just let me rewrite it”. The answer is still “no”. You get back to work.
  12. Before you know it, the project starts shaping up and it is actually going well. You look back and think, “why didn’t the previous developers do all of this good stuff that I’m doing?”
  13. Eventually, a new developer joins your team.
    1. After a day of looking at the project, he comes to you and regales you with his assessment of the project, “it is a terrible mess.”
    2. “Can we just start over?”
    3. You tell him “no”.
    4. He seems frustrated and a little demoralized.
    5. After working with the code for a week or two, he catches-up with you and is actually doing well.
    6. He comes to you with ideas about how to improve the project
  14. You get pressure from management to stop refactoring things and focus on adding new features. You find that you have to cut a few corners and occasionally leave some technical debt.
  15. A new technology emerges in the IT community and you want to embrace it, but that means you would have to overhaul, or rewrite the current app. You know that would never fly. If it did, management would just farm the project out to a contracting firm who would put the project back to where it was on day 1.
  16. You stick with the project as-is.
  17. Eventually, some hot-shot comes along and pitches the idea of replacing your project with something just like it, but instead “the new product” will take advantage of the latest technologies. Basically, it is the same idea that you had, but you didn’t push it because you know where it would go.
  18. Management is dazzled by the sales job and writes a check before asking you. You jump-in and say your team could have done it for half the price, but management scoffs, because you guys are booked full-time on maintaining the current project. You couldn’t possibly spare the time to make a replacement product.
  19. You get “volunteered” to gather requirements for the new system. These new guys are very irritating and short-sighted. You kinda hate them.

And thus is the circle of life.

As always: disclaimer: this is not about my current project. It is about every project.  If you don’t believe me, please show this to another developer and ask if any of this sounds familiar. LOL.

I hope you found it entertaining or perhaps even therapeutic.  🙂

Posted in IT Horror Stories | Tagged , , , | Leave a comment

“People aren’t afraid of failure, they are afraid of blame.”

– Seth Godin

Posted in Career | Tagged | Leave a comment

You got time to lean, you got time to clean

The first time that I recall hearing this saying, was while watching “the great food truck race” with Tyler whats-his-face. He was schooling some of the new food-truck chefs to clean up, after a long day of working. I was somehow deeply inspired by this saying. I can’t believe that I’ve never heard it before. This sounds like the kind of thing I would have heard while I was in the army. Maybe I wasn’t listening at the time.

I’m a naturally active person. I just can’t sit still for long. When I was a kid my parents often accused me of having “ants in my pants”. Even as an adult, if there is anything I need to be doing, I just can’t sit and relax. A person does need some down-time, but that doesn’t mean you by-pass your work. It means you need to catch your breath, and then get back to work and earn an “A”.

I often hear about teams who seem to accumulate technical debt. When I hear about it, I have to scratch my head and think about how this is possible. How could you just accumulate technical debt, and just like, leave it there? When you eat a candy bar, do you just drop the wrapper where you are standing? When you finish dinner, do you just walk away from the table without clearing it? Does your trash can just walk itself to the curb each week?

How does this stuff not haunt you at night?! If that was me, I would seriously wake up in the middle of the night, because I had a nightmare about technical debt, waiting for me, and I can’t get back to sleep, so I would have to pace until sun-up. Can people actually sleep through stuff like that?

I suppose some people may try to justify it with logic like, “I’m just too busy, making new stuff and meeting aggressive timelines”. When they get some down-time, there are more excuses, “I’ve been stressed by my busy schedule. So now, I require this quiet time to recharge and unwind, rather than doing more clean-up work”.

I don’t buy it. My parents raised me on the following concepts:

  • A job isn’t done until you’ve cleaned up after yourself
  • If you got it out, you must put it away
  • If you touched it, you are now responsible for it
  • When you use a tool, return it in better condition than you found it
  • Clean up after yourself, as you work. If you leave your messes till the end, they will seem too big to handle
  • Cleaning up is not somebody else’s job. Have the dignity to clean up after yourself. It shows respect for others.
  • It doesn’t matter if you made the mess. Just clean it up. Messes don’t ever seem to clean themselves up.

Bottom line: Don’t leave technical debt. It is the same as leaving any other mess or trash, laying around. It is disrespectful to others and it shows that you have a lack of dignity for others and yourself. If you’ve got time to lean, you’ve got time to clean. And if you don’t have time, then make the time. Seriously, you can’t live with garbage lying around at your feet. Bend over and pick it up. Clean it and put it away where it goes.

Get it done and then enjoy your down-time with a free conscience.

 

Posted in Programming | Tagged , , | Leave a comment

Knowing when to read the signature from an Ingenico iSC480

I’ve been working on a project to integrate my team’s POS (point of sale) software with an Ingenico iSC480. The device is pretty nice looking and some of the API stuff is pretty easy, especially since you can get an example app from Ingenico, and it shows how to do nearly anything.

However, the example apps don’t seem to show how to detect when the user is done signing. I had to figure it out from the examples.

So, I would like to share two ways of doing this. I call them “the not-so-obvious way of detecting when to get the signature” and “the not-obvious-in-any-way method of detecting when to get the signature”. Catchy names, eh?

1. The not-so-obvious way of detecting when to get the signature
Even though this way is “not-so-obvious”, I still figured it out. The API contains a command “M29”. This asks the device if any recent signatures have shown up. This command always gets a reply. You can set up a timer loop to keep asking the device the same question. When the user is done signing, the reply (from the M29 command) will have a status greater-than zero. This indicates the number of chunks that the signature has been broken-into. Zero chunks, means no signature.

2. The not-obvious-in-any-way method of detecting when to get the signature
I discovered this approach after reading-through a bunch of config files. I do stuff like that, just because I’m curious and I like to see what is in them. Sometimes you find the coolest stuff. Well, surprise, surprise! In one of the config files I found that it is possible to set the device to send a message when the user is done signing. You would think that would be “on” all of the time. Nope. To turn it on, you have to send a M60 command. Set option “0009” with a value of “0002”. From now on, the device will send a “20” message, when the user is done signing.

There you go. I hope that made your job a little easier.

Posted in Programming | Tagged , | Leave a comment

Letting go, delegating, managing

Let’s just say that you are a programmer, or server admin or just about anything, and you are really good at what you do. Usually, this means that you are a person “who gets things done”. This also usually means that people know this about you and so you get a lot of work assigned to you.

Eventually, people will want to test your capacity, and then determine if you can be pressed to exceed your capacity. In other words, you are given more work than you could possibly complete. Way more.  Some of it is just not going to be done, unless something changes.  At this point, management can decide to press you down one of two paths:

  1. Give you less work, so you are at (or slightly below) your capacity – or –
  2. Press you to learn a little trick called “delegating”

As you can imagine, option 1 only happens if you just start dropping work, refuse to do more work, and refuse to delegate. Basically you declare that you are a bottleneck which is “this big” and you will never be more than that.  So be it.  You are now labeled.

Option 2 is a little more interesting, but it requires growth, and growth is often painful. If you go down this path, the first time will be the most difficult.  Here is what will go through your mind:

  • It would probably be quicker if I just did it myself, instead of taking the time to explain it to someone else, who will take just as much time as me, or maybe longer.
  • If you want it done right, do it yourself. I know I will do it right.
  • If it is not done right, I will have to redo it, or train my delegate how to do it right. *sigh*
  • I will only know if it was done right by reviewing it. That just adds more time too.
  • Gosh, this is a lot of work to delegate things. I need to pick which tasks to delegate and think about all of this stuff. It is a lot to think about. It will certainly drain a lot of time out of my schedule and the schedule of others
  • I just can’t see how this is efficient. I keep going back to my first statement, that it would be quicker if I did it myself.
  • Seriously, I just am having trouble getting over it. The inefficiency if it all is causing a burning sensation inside.
  • Maybe I can sneak in there and do most of it myself and only make it seem on the outside, like I’m delegating stuff. That way, I avoid all of this inefficiency.
  • Dang it! When I try to sneak like that, I just end up with even more work, but with no ROI. Plus, my delegate is getting mad that I’m giving him “busy work”, which is way below his actual skill level.
  • If I was already done, then I wouldn’t have to go through this big transition.
  • I wish I was done, but I’m not, so I need to let go and honestly delegate.
  • I sort-of feel like a failure, because I was always the guy who got stuff done, but from now-on, that will be someone else. Buh-bye hero badges. It was nice knowing you.

It is a little like the psychological stages of grief. With steps like resistance, denial, negotiating, acceptance, um and the other steps.  Delegating does not sound like much fun.  Why is somebody putting you through this pain?

Then you get a grip and remember that you are *one* person.  Last year, you were not as good as you are today.  Somebody invested some trust in you and allowed you to achieve the great things that you have achieved today.  You can’t be the only person in the world who has this potential.  There must be others.  Your subordinate, could possibly be the next “you”.  He just needs to be led to the same place that you are.

And then, what about you? When you have led others to be as good as (or better than) you, then what about you?  Will you still be needed?  The answer is emphatically “yes”.  Because you are a person who makes more “you”s. Who else does that?  You do.  Your next move, might be to make more “you”s who make more “you”s. Dang!

Let’s not get ahead of ourselves. Shall we. Let’s just start by delegating.  It is hard enough, for now.

Posted in Career, Professionalism | Tagged , , | Leave a comment