Time management - no documentation provided

Question

My situation: I recently migrated my company's old ordering system to a new one I developed for them. It had to be backwards compatible and work with the existing database structure until the migration was finally completed. Now that the migration is partially complete, I would like to redesign the database, but I find myself almost 100% of the time supporting the interface, and existing idiosyncrasies of the old database structure. I'm not given any time to document anything so updating anything requires me to rely on the comments I created when originally developing the application.

Not only do I now have to support it for every department, but it seems like even more projects are being thrown at me - which are all getting triaged, and some take weeks before I can even look at them. I hate to do sloppy work in order to get everything done, but it seems like that's where I'm headed :(

I was wondering (and hoping) if anyone is/was in a similar situation and share their insight and perhaps give me some idea's before I rip my hair out :)

Answer 1

Interesting that I would read Jeff's Coding Horror. Check this out.

Answer 2

Its called Technical Debt. There's been a lot of discussion about it here recently. Do some searching on that topic here and check out the links below. You basically need to convince your management of the need to pay down this debt.

http://www.codinghorror.com/blog/archives/001230.html

http://www.martinfowler.com/bliki/TechnicalDebt.html

http://en.wikipedia.org/wiki/Technical_debt

Answer 3

I think that the 'piece at a time' approach applies here. If you can refactor part of the code every time you triage something or add a feature, you'll at least make progress. I know that every feature is 'critical' and needs to be implemented 'immediately', but you should be able to push back with some reasonable explanations why the work needs to take a bit longer.

Answer 4

In response to "I don't have time to document anything". Set up a WIKI to take notes with. Specific aspects of WIKI's that are useful in this type of situation are:

• They do not require you to document the information in a linear format (because lets face it, in our kind of work we are constantly dealing with a large network of interelated facts)
• There's no obligation to really complete any documentation you start - you can always go back later. This is actually a good thing. Pressure to document something properly can often stop you from documenting it at all. Just write some stuff onto the WIKI as you go.

As you work through a problem, document your train of thought on a WIKI page. Next time you encounter the same problem, try and use your previous notes, and fix up all of the things you glossed over the first time.

The quality of the documentation you end up with often turns out to be surprisingly good, because it contains information that is actually needed.

Answer 5

"I'm not given any time to document anything"

Let me pick at that one. You should not be given the time, take it.

Don't individually line item things like documentation and testing, same as you don't individually spec time for comments and indentation. It's necessary to do the job right. The client will always try to remove them to shave time/money, but it's as ridiculous as hiring a carpenter and then complaining that they're wasting time measuring things! It would be equally as ridiculous for the contractor to charge for measuring. Just include the time you need to doc and test in your total estimate for how long a project will take.

It also suggests that you're writing docs after the code is written. Do it as part of your normal development rather than at the end in a big lump. It will be far easier and more effective that way. Use documentation, but user and API docs, to offload information from your head so you have to juggle less and have more brain power for the moment.

If they find out you're "wasting" time on documentation, explain that it will save time in the short term and then lose time as the project develops further, gets more complicated and you can't keep it all in your head. It also means you're not critical to the process which means you can get sick, do other work, or even quit and the project can be taken over by someone else. This reduces project risk. It is referred to as "increasing the bus number".

Answer 6

Sounds like there are two sides to this:

1) You're having to work with lots of legacy code. I'll let other people talk about how to manage that, but suffice to say a "big bang rewrite of everything" is not the right way to do it.

2) It sounds like you're feeling pressured into rushing things and producing substandard work as a result. If this is true, here is some advice (taken from this awesome book and my personal experience.)

When someone comes to you and says "How long will this take", you need to give them an honest answer. Give them the "do it properly" answer, not the "quick hack" answer.

So, if you say "6 to 8 weeks", you'll most likely get back "that's way too long!". This is where the pressure comes in.

Here is where most programmers kind of just give up, and give in to the pressure to do a crappy job because they feel like if they rushed it they could do it in 3 weeks. Don't do this. The person asking you to do the work is trying to get their own problems solved, and you're not doing them any favors by delivering substandard work. Remember it's your job to work with them to reach the best conclusion.

Some examples of this in practice are discussing and saying stuff like "well, there are 5 parts to this, if we leave this one out we can get it done in time". If that doesn't work then you have other options such as "if we can get carl or john to do these 3 other bits then it will cut down the time by 2 weeks".

Remember, you're working with the other person to develop a plan to get things done. You're not fighting against them! If you keep this in mind in my experience about 80% of the "pressure to do crap work" goes away.