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

Wheels that need to squeak

I’m sure you have heard the phrase “the squeaky wheel gets the grease”. Basically, if you need something done and it is not just getting itself done, you should speak-up and complain, maybe even make a bit of a ruckus, and be persistent.  If you become enough of an annoyance, someone will put in the effort to satisfy you, just so everyone can get some peace.

In fact, this can be a pretty good indicator of how some places are functioning (or not).

I think back to a place where I was hired to “fix everything, because everything was broken”. During the interview, the HR folks seemed unusually honest about their dire situation.  It was a bit unnerving, but I appreciated the honesty, and I took the job.  Honestly, I love challenges, and this just seemed like too much fun to pass-up.

It took a few days for me to plug-in and start fixing things. As I did, I also surveyed the landscape and determined how vast and pervasive, was the “brokenness”.  I started putting numbers on things and assembled a priority list and a timeline.  When I passed this recommendation up to my boss, I became aware of a barrier which was a nice contributing factor in the current situation.

Each day, I was visited by several people, and received several phone calls. Each of these people would talk about an IT problem that they were dealing-with and then they campaigned for me to fix these problems.  It was probably the only place where I have seen such a consistent and organized process where each person had to be the PM for his/her fix.  As soon as I started working on each problem, another person would interrupt me and try to persuade me to work on his/her problem instead.  Needless to say, it was hard to make any progress on any of the issues, with the constant interruptions.  However, each day, it was the same thing.

Somehow, the system at this place was set up to reward the “squeaky wheels”. If you didn’t squeak often enough, you didn’t get any grease.  So, the whole building was a disorganized orchestra of squeaking.  It desperately needed to change.

My boss had taken-over the department a few months before I arrived. She already seemed to have a feeling about how normal/healthy the current process was.  When I went to her office to discuss it, I didn’t even have to finish my sentence.  She was waiting for this conversation.  It was time to enact some changes.

Making a Change

The new process went like this:

  1. If someone came to me, I sent them to my boss
  2. My boss put the work/request into a work queue (initially, a SharePoint “to do” list).
  3. Once it was on the list, I determined a duration of each task
  4. Once I set a duration, my boss would set the priority
  5. Each day, I would work on the highest priority items
  6. At the end of the day, I would review and score any new items
  7. Once per week, my boss would evaluate and re-shuffle the list

Short-term Results

I’d like to tell you that everyone thought “the new process” was the right answer, but ehem, that is not even close.

The old process had rewarded people who were squeaky wheels, and who were resourceful and persuasive. Everyone at that company had been conditioned to follow the old process. Nearly everyone had developed their persuasion skills very well and applied those skills with diligence.   The natural response to our new process, was to squeak louder, and use more persuasion.  Repeat, until you got some grease.

To make our changes stick, we had to stand our ground. We would listen to reason, but any campaigning would be dismissed, because it was only a tactic and not business-driven.  No amount of song-and-dance would sway us.  Pretty quickly we were labeled as heartless monsters. Clearly, it had to be because we hated nice people.  Every ounce of it obviously was personal.  The terrorists have won, etc.

Weathering The Storm

As we focused on the most pervasive and widespread problems, the problems seemed to get resolved at an increasingly rapid rate. Fewer interruptions meant more time focusing on fixes, rather than negotiating and tap-dancing.  Pretty soon, we had cut the list in half, and then half again.  Unfortunately, some of the bugs did not rate high enough to get serviced.  In fact, some of the apps were cancelled, removed or shut-down.  You can imagine the waves of emotion that roared when we did this.

In the end, we built a better IT department with systems based-on business-need rather than emotion. There were still a few people who tested the waters occasionally and tried being squeaky wheels.  My boss and I actually turned that into a metric.  We expected a specific level of squeakiness within the organization.  It needed to be “not too low and not too high”.  When it was “just right”, we knew we were operating at a high level of efficiency and professionalism.

The net take-away from the experience is that there should be some wheels squeaking, occasionally.  You cannot please everyone.  Therefore, if there is no squeaking, you might not be making all of the right decisions and moving your timelines and projects with enough aggression.  Move closer to the edge. Squeeze some of your timelines a little.  Push a feature or two, out-of-scope.  This is how you tune your team for higher efficiency and better ROI.  Of course, “less-is-more”, but likewise, “none” is too little.

Posted in IT Horror Stories, IT Psychology, Lessons Learned, Methodology, Professionalism | Tagged , , , , | Leave a comment

Both sides of craftsmanship

I recently read a good article titled “The Dark Side of Craftsmanship“. In the article Ted Neward tells a story about a well-meaning developer who posts some sloppy code to a public forum and is criticized harshly. Mr. Neward correctly points-out that the criticism was over-the-top and downright rude and un-classy. You had to feel bad for the victim because she was trying to be nice and participate in a public forum. The criticism was not constructive or helpful. Mr. Neward continued by pointing-out that not everybody needs to be a ninja and it is okay to be a code slinger because the world needs some of them too.

I must confess that I wholeheartedly agreed with his article until I started thinking about the other end of the spectrum. Then I wholeheartedly disagreed at the same time. Oh, such inner conflict! I nearly became emotional.

The point Mr. Neward was trying to make is that some people get carried away with elitism and forget their original purpose. Bottom line: programmers just produce programs that provide a service to people and you don’t need to be a fancy-pants to accomplish that goal. Elitists sometimes get caught up in their own glory and tend to look down on others who are not on a quest for self-perfection.

To that end, I say bravo. One of my favorite battle cries is: “First, get it done. Then make it better.” Overcomplicating any project is a mistake clothed in artificial brilliance. An over-complicated program will get rewritten every time (that is, if it is ever completed in the first place).

The only problem is that some people misuse this rationale as an excuse for carelessness and for delivering poor quality. I have been criticized that “First get it done. Then make it better.” Often gets truncated after the first sentence. People try to “first get it done” and then move-on and never make it better. They leave you with a stinking mess and say it was Tim’s idea. So be careful with that.

Every project that you do, should be written rapidly and reliably to meet the needs of the project with regard to usability and maintainability, without overdoing it. For example: If I am making a data-loading app that only needs to run once and never run again, then I really don’t need a fancy UI, or TDD, etc. I know it is a disposable program and it won’t be anything else. I provide the best value to my employer by keeping the cost down and the timeline short by getting it to work as soon as I can. However, if I am whipping up a quick prototype that I suspect is somehow going to get deployed as a production app and won’t be replaced for 5 years, then I really should feel obliged to put a little more quality behind it. This is even more critical if I suspect that somebody else may have to maintain any of it. The solution should fit the problem.

Bottom line: provide a good value to your employer.  Find the balance between hack and perfectionist.

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