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. (but not because there actually is nothing wrong with them. You are just feeling jealous.)

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.  🙂

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Horror Stories, Lessons Learned and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s