How to deal with the frustration when a project is delayed for an indefinite amount of time...

Question

Right now, I'm extremely frustrated because I was in the process of developing some cool mechanism to optimize a calculation system by reducing the number of calculations from around half a million to just a few thousands. It took a lot of time examining and analyzing data, writing things down, doing a few tests and in general just doing my work. Then we had a project meeting. I've explained what I wanted to do, how much time it would take and how much it could improve the project and even make it possible to create new features. Then it was decided that it was just too much time to do this all before the next deadline. (A deadline which would have to be extended if I was allowed to continue.) A quick brainstorm made it clear that there is an easy work-around that could be used instead, which would delay the optimization for a few more months.

Well, tough!

Okay... I've just written the frustration away. Now the question... I now have this whole design in my head. Much of it are just schematics and pieces of papers with handwritten text on it, some printouts and even a few questions here at SO. These ideas will be frozen for a while, but I will need to remember them in the future again. I can get a day, maybe two to clean up the notes and start documenting things.

So I need advise on how to best remember my design in e.g. 4 months from now. Or maybe even a year from now... What would be the most important to write down? Or document? (Considering the short amount of time I have...) Any suggestions?

Why? Else I'll just be frustrated again four months from now. :-)

Answer 1

In my experience old designs always seem stale when dusted off. In the coming months the existing code will change, the requirements will change, and you'll change as a programmer. Maybe you should write up a brief explanation and assume that you'll need to completely rework it in the future anyway.

Don't get frustrated with specific projects, focus your energy on improving as a developer. And carry that experience with you.

Answer 2

It depends what works for you -- and how you like to learn. I like to use diagrams, so in the situation where I've designed a cool algorithm (albeit nothing as complex as this!) I do the following:

1) Draw the algorithm out on paper, or write it out whatever.

2) Add annotations to it so that it makes complete sense to you.

3) Describe the algorithm to someone else from only what you've drawn. This stops you from filling in blanks from your own knowledge of the algorithm.

4) If there are gaps in your description, add extra detail as you go, so that the document becomes a comprehensive record of your description.

5) Put the drawing away for a week and see if it still makes sense. At this point it should still be familiar enough to add missing detail.

Whether it will be clear enough in a year's time -- or whether you'll even want to use it -- remains to be seen.

Hope that helps!

Answer 3

A detailed requirements document that describes all inputs and outputs is probably one of the best ways to get started. If its a very unique code design, metacode might be a good step. ie.

[Meta Object]

     [Return String(string param1, string param2)]

        Return param1 + " " + param2

     [Return Integer(integer param1, integer param2, integer param3)]

        Return (param1 + param3) / param2

[End Meta Object]

Make it look something similar to your language w/o testing or anything, just get the theoretical logc onto paper (notepad) that way you have a spring board when/if you ever have to go back to it... then document the daylights out of it.

Answer 4

In terms of the frustration - generally try to view a project as a journey rather than a destination.

If you've been paying attention you'll have got a lot out of the project to date - things you've learned about the technology and the business, created modules of code you can reuse, you'll have built relationships with team members or users, made mistakes you won't make again and so on. It might help you personally to write a list of what you know now that you didn't at the start of the project.

Ultimately the company may not have implemented the project but much of the benefit which accrues to you as a person and a developer is still there. Indeed, often you learn more on projects which go wrong and in companies which aren't great than when things are running like a dream.

As with the rest of life, the more satisfaction you can get from things day to day, and the less you focus on only the marquee achievements, the happier you'll be.

I'm not saying that delivering projects isn't good - it's obviously why we code - but it's not entirely inside our control so you need to be realistic and balanced about how much you let that impact you.

(The obligatory link to something Joel or Jeff wrote: http://www.codinghorror.com/blog/archives/001297.html)

Answer 5

If you have found the Solution once, chances are high you will find out solution even 4 months down the line for the same problem. What you MUST not miss is the actual problem.

You should pen-down all the optimization problems which are the problem-sources or the actual problems. You must neatly maintain notes of these problem issues.

Now, Next time [say 4 months down the line] when you want to come back to this again. You just need to read the problem issues from your notes, and your brain will start working in the straight direction as it did previously.

To make it even better, you can try going through the problem notes once in a month or two. This will train your brain towards the solution as you will every-time end up with the solution just as you did for the first time.

Also if you can pen-down the issue or concern which actually motivated you enough to struggle for the solution, it'd be great.