How to manage a project when it is frozen / postponed indefinitely

Question

Currently, I am very upset because I was developing some cool mechanism for optimizing the settlement system by reducing the number of calculations from about half a million to several thousand. It took a lot of time analyzing and analyzing data, recording things, doing a few tests and generally doing my job. Then we had a project meeting. I explained what I wanted to do, how long it would take, and how much this could improve the project and even create new opportunities. It was then decided that there was too much time to complete all this until the next deadline. (The deadline, which should have been extended, if I was allowed to continue.) A quick brainstorming session made it clear that there is a convenient job that can be used instead, which will delay the optimization for a few more months.

Well, tough!

Okay ... I just wrote disappointment. Now the question is ... I now have all this in my head. Most of them are just diagrams and pieces of articles 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 clear notes and start documenting things.

So, I need advice on how best to remember my design, for example. After 4 months. Or maybe even in a year ... What would be the most important thing to record? Or a document? (Given the short amount of time I have ...) Any suggestions?

Why? Otherwise, I will be upset again after four months .:-)

Answer 1

It depends on what works for you - and how you like to study. I like to use charts, so in a situation where I developed a cool algorithm (although nothing complicated like this!), I do the following:

1) Draw an algorithm on paper or write anything.

2) Add annotations to it so that it gives you full meaning.

3) Describe the algorithm for someone else only from what you drew. This prevents you from filling in the gaps from your own knowledge of the algorithm.

4) If there are spaces in your description, add additional details as you go so that the document becomes an exhaustive record of your description.

5) Set aside the drawing for a week and see if it all makes sense. At this point, he should still be familiar enough to add the missing details.

Whether this will be clear enough in a year — or whether you want to use it — remains to be seen.

Hope this helps!

Answer 2

In my experience, old projects always seem stagnant when steamed. In the coming months, existing code will change, requirements will change, and you will change as a programmer. You may need to write a brief explanation and assume that you still have to completely redo it in the future.

Do not worry about specific projects, focus your energy on improvement as a developer. And bring this experience with you.

Answer 3

In terms of frustration, usually try to view the project as a journey, not a destination.

If you noticed, today you will have many opportunities for the project - everything that you learned about technology and business, created code modules that you can reuse, you will have built relationships with team members or users, made mistakes, which you will not do again and so on. This can help you personally write a list of what you know now that was not at the beginning of the project.

In the end, the company may not have implemented the project, but most of the benefits that accrue to you as a person and developer still exist. Indeed, often you will learn more about projects that go wrong, and at companies that are not great than when everything works like a dream.

As in the rest of life, the more pleasure you can get from everyday life, the less you focus only on the achievements of the tent, the happier you will be.

I'm not saying that project delivery is not very good - it’s obvious why we code, but not completely within our control, so you need to be realistic and balanced as to how much you allow this to influence you.

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

Answer 4

A detailed requirements document describing all the inputs and outputs is probably one of the best ways to get started. If this is a very unique code, a metacode can be a good step. i.e.

[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 like your language without testing or anything else, just get a theoretical log code on paper (notepad) in such a way that you have a spring board when / if you ever have to go back To her. then document the daylight from it.

Answer 5

If you find a solution once, the chances are high, you will find a solution even after 4 months on the same problem. What you SHOULD NOT miss is a real problem.

You should look at all optimization problems that are problematic sources or current issues. You must keep a record of these issues.

Now, next time [say, 4 months down], when you want to come back to this again. You just need to read the problems from your notes, and your brain will begin to work in the forward direction, as it was before.

To make this even better, you can try reviewing problem notes once a month or two. This will teach your brain the solution, since you will at any time end up with the decision, as you did for the first time.

Also, if you can postpone a problem or a problem that actually prompted you to struggle enough for a solution, it would be great.