I think every developer, specially in-house one, gets once in a while assigned a project he or she hates. OK, so perhaps hate is too strong of a word. Still, if it happens too often, nobody could resent the use of word hate.

Anyway… I stumble on this sort of project once every three to four years. Projects differ as much as a kangaroo differs from a hypo. At previous gig it was working on a cloud based solution. At current gig it is a customer relationship system. It doesn’t really matter. It could be an app for counting wildebeests. The thing that matters is how you get it done. Professionally.

In my opinion, there are four things you can do:

  1. You can change jobs. This is considered drastic and is bound to make you unpopular. Specially, if you go in the middle of a project.
  2. You can try and convince your peers to assign project to someone else. Here you will need sound arguments (as “I don’t want to do it” just doesn’t cut it), good negotiating skills and a reasonable boss. It is a risky move, as it will make you unpopular with your boss, if you fail or it will make you unpopular with your co-workers, if you succeed. Unless there is someone else eagerly waiting to get this project, I strongly oppose you take this action, unless you don’t want to stay at current gig anyway, in which case, you would be better off just following option 1.
  3. You can bitch to anyone who is willing to listen. This might get you sympathetic looks from co-workers, but your peers will get the feeling you are just bitchy. However unprofessional this sounds (and is), it actually works in public offices. People that bitch the most, get the least work, but are payed better, which in turn makes their co-workers like them less and gossip. In private held company, doing this will (hopefully) get you the boot. If I was strongly opposed to option 2, this one is even worse. It not only makes you unpopular, but it proves to everyone you are lazy, annoying and will do anything to achieve your thing. Nobody likes that.
  4. You can “take one for the team” and do the project. This will leave scars. Physical (from grinding teeth) and mental (from convincing yourself you actually LOVE this project). On the other hand, it will not change your status with co-workers and could give you bonus points with your peers. If you do it professionally. If you whip out a half-ass product, you are better off not doing it at all as it will hurt your reputation.

 

Assuming you don’t want to switch jobs, lay unwanted project on anyone else or behave like a primadonna, I am suggesting you do the following:

  1. Create specs, if they don’t exist. I know, I know. We developers can’t write. Lame excuse. We all know that practice makes perfect. So writing specs will actually help you be a better writer.
  2. Get whoever assigned you the project to sign on specs. Sure, specs will change during implementation, but by getting your peers to sign the specs, you make sure no new big features will hit you later on and your peers get a preview of what you are about to do. So, it is a win-win situation.
  3. Split work done into smaller tasks assign them valid priority and do an estimation of work needed. This will get you a pretty much valid schedule and there is nothing better than knowing when the terror… ooops, I mean project will go into alpha and beta testing.
  4. Sort tasks by priority and get them done one by one. Why sort it by priority? If you get all the hard work done at the start, you will be left with fun things (i.e. tinkering with UI) and your schedule will be more correct. Also, you can cut low priority features without losing functionality, if you are in hurry to meet a deadline.

 

Now, this presumed you are working on a project alone. If you are working in a team, you may not have the authority to do all this on larger scale. However, there is nothing stopping you to do this just for your own work.

Remember that cloud based solution I was telling you about? There was no specs for the darned thing but a one line e-mail some middle manager sent at 1 am. This led to every middle manager connected to the project having their own special feature and came up with gazillion others during a project development cycle, causing project to be developed indefinitely. Without a bright light at the end of that tunnel, entire project team became irritated and confused as to what the system should be doing and why. This was not the first time that it happened, so after alpha testing, I decided it is best for me and the company that I look for another job.

The CRS project has another problem. I have written the specs, split it into smaller tasks, sorted them by priority and completed, but didn’t insist on my peers to sign on specs. What happened? Nobody read the specs or gave their input until alpha testing. And I begged! Nada. Not a single line e-mail. Later, in alpha testing, suddenly people got all kind of wild ideas for this version and since specs have not been signed on, I had to implement those as well. Don’t get me wrong. The implementation was not a problem, the problem is that it took me 8 hours to change an outline and behaviour of one form, when, if specs were read and commented upon, it would take 1 hour to fix a Visio drawing, 30 minutes to describe behaviour and those 16 hours implementation took anyway. So, take my advice and insist on getting specs read, commented, fixed and approved or signed. It will be worth a while.