Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

This is something that happens to almost every project I am involved in as a developer. At first when I am presented with the problem I am very motivated to find a solution for it. And I develop on a rapid pace, however, when it reaches to the end of the project and I have almost solved the problem and it is just matter of fixing small bugs, or renaming some methods/function or optimizing the code I suddenly lose interest in the matter.

I have read Mihaly Csikszentmihalyi's state of flow article, and I think it might be related to that as explained here. But I am still thinking if there is a way or method or development approach which keeps you motivated towards the end of a project. The approach I mostly take is first get everything to work as they supposed to and then find the best way of solving the problem.

I was wondering if there is a way to develop at a steady pace and still be motivated while the project is finishing?

share|improve this question

marked as duplicate by gnat, Bart van Ingen Schenau, Jalayn, Steve Evers, MainMa May 1 '13 at 17:25

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
Not a full answer, but i motivate myself with self rewards, e.g if i solve X things in Y time i give myself something i wanted outside of work. May seem silly but it works for me! –  RhysW May 1 '13 at 9:50
1  
BTW It is not about the state of flow, it's just that the everyday things you're doing change. In the beginning you're doing large-scale construction and solving broad puzzles, then you move into the smaller parts of laying down the bricks that make the building and you have smaller puzzles, and finally you're only testing and fixing and there's almost no creative process anymore. I suggest you distinguish which of these task you like and dislike and take on the dislikes. –  Jan Doggen May 1 '13 at 10:29
    
@JanDoggen what you are saying is very true... I guess I need to take the whole process of developing software as a whole, as one big puzzle as you mentioned, and in order to solve the whole puzzle I have to solve everything. But I was just curios if following a certain development approach would make it easier for me. Like after having the rough design of the whole project, I implement every thing perfectly before I start doing the next component, something like TDD –  mrz May 1 '13 at 11:43
    
@RhysW that can work in one project or two, but I am looking for some long term solution because right now I start to feel maybe I am doing something wrong. Because I like t code and I have a little OCd about it, and about the way I code. So I like to code clean and test everything before giving it to customer, but at the end it is just hard to make my self convinced that I need to finish it, nevertheless that getting paid after the project can be the best reward –  mrz May 1 '13 at 11:50
2  
Here's good plan: 1) when it gets boring, stop doing it 2) But you need to work extra hard at the beginning to avoid bugs - if there is a bug, you made a mistake earlier –  tp1 May 1 '13 at 12:01

5 Answers 5

up vote 2 down vote accepted

The only surefire way of handling this that I have found is to have a sense of pride in your craftsmanship. It's the same as a carpenter making say, a chest of drawers. The problem is essentially "solved" once he has the wood shaped how he wants it and fastened together to make a serviceable piece of furniture. The craftsmanship comes in with the sanding, finishing, varnishing, and general beautifying. If you approach software development in the same way you will most likely find that the hundreds of little details that go into finishing everything off once the problem is solved can be as enjoyable in their own way as solving the original problem.

A healthy dose of OCD tends to help with the whole process too ;)

share|improve this answer
    
+1: Great analogy. –  Jim G. May 2 '13 at 11:01

The problem, I think, is that you know that you must do a lot of small tasks, but you don't know which exactly. So the tasks become an enigmatic mass of entangled problems, which weighs upon you and leads to anxiety, which leads to procrastination.

The goal is, then, to take stock of your tasks and structure them.

For example:

You've almost finished developing a website, but there are a few problems that you must taclke.

Firstly, let's list them:

  1. Complete cross-browser compatibility for IE8.
  2. Check for inconsistencies between your web page and mock-ups.
  3. Fix a small bug in the server-side form validation script.
  4. Decide upon an animation effect for a dropdown effect.

This feels better, because it's actually not too much. But there's still anxiety left, because you don't know how exactly you will tackle these tasks. So let's divide them into as many meaningful substeps as possible.

  1. Complete cross-browser compatibility for IE8.

    1.1. Check the website in IE8 and compare it to the browser of your choosing.

    1.2. Find and list the inconsistencies. (you can list them right here later!)

    1.3. Remove the inconsistencies.

    1.4. For inconcsistencies that couldn't be removed, plan graceful degradation.

    1.5. Discuss with the designer about your plan for graceful degradation.

    1.6. Implement graceful degradation.

  2. Check for inconsistencies between your web page and mock-ups.

    2.1. Check for inconsistencies each webpage of your site (list the pages here)

    2.2. Fix the inconsistencies. (list the inconsistencies here)

  3. Fix a small bug in the server-side form validation script.

    3.1. Find the cause of the bug.

    3.2. Fix it.

    3.3. Run unit tests.

  4. Decide upon an animation effect for a dropdown effect.

    4.1. Propose a solution or contact a designer for a solution.

    4.2. Implement the solution.

    4.3. Run unit tests if applicable.

    4.4. Check for crossbrowser compatibility.

    4.5. Implement graceful degradation if neccessary.

Now you have a full picture of what you must do, and there is much less anxiety about the upcoming work. There will be no surprises along the way (or at least not as many as there would've been). Now you can focus on tackling the tasks and forget about everything else.

As you go on about completing them, you remove them from this list.

Workflowy is a really useful tool for this, because it's basically a list creation application, so moving list items around, striking them out or changing the hierarchy is really simple.

share|improve this answer
1  
Very good answer. I may add that it's a well known fact that when you check something on a list, there is a release of endorphin in the brain that make you feel good. The more things you got on your list and the more often you check it, more endorphin in your body. But don't put to much things on a list because it can create more anxiety. –  Jean-François Côté May 1 '13 at 17:04
1  
I found that even very long lists are less anxiety-inducing than shortened ones, esp. if you've consciously omitted some items. The list is just a more-or-less objective picture of your subsequent work. If this pictures makes you anxious, perhaps your time or budgetary constraints are wrong, and it may be a good time to rethink or re-negotiate them. –  exizt May 1 '13 at 17:50

I was talking about something very similar to a co-worker of mine the other week. I was in a bit of a "funk" and wanted to get out of it. I asked him how he maintains his productivity. He explained to me that he maintains two lists.

  1. A priority sorted list of stuff that needs to get done. This includes primary tasks, sub-tasks, wishlists, ....
  2. A calendar sorted list of stuff that he has accomplished each day.

As each item from list 1 is finished, it is moved to list 2.

How does this help?

As these lists are always open and updated, he can always see what needs to be done AND what he has accomplished. When it is observed that the "accomplished" list is getting pretty sparse for a couple of days, he knows that there is an issue. Usually, the work item needs to be broken up into smaller chunks--even if it is a small or simple as making notes about an unfamiliar module. Sometimes, a switch to one of the other items from list #1 is the psychological trick that is needed.

I've since tried adopting this style, and it got me out of the funk quickly. It also helps when it comes to annual (or quarterly) reviews as there is a ready list of tasks that have been done since the last review.

I hope this helps.

share|improve this answer

All you need to do is changing your perpestive on software development. Normally you shouldn't have to do that much of "small things" in the end, because most of these stuff needs to be done during the development period of each feature of a project.

For example if you are going to use the Agile software development method, you will find yourself developing in small iterations of doing the same things (designing, coding, testing) more or less depending your progress.

So nothing is actually left for the end, and when a single iteration ends you should have a piece of software that is tested and successfully build with no errors on all target environments.

If you make yourself comfortable with this kind of thinking you should always have a steady "pace" when developing a software project as you are constantly doing the same things over and over and won't lose your interest and motivation.

Take a look at this wiki article http://en.wikipedia.org/wiki/Software_development_methodology

You will also find a lot of stuff in the web about the software development process.

share|improve this answer
    
CAnt agree more that if you follow true agile, you should be done with the task in each iteration at the end of one. And that of course includes testing, design and development. Good thing about agile is you still have to do some designing in the next iteration which may keep me motivated until the end. –  mrz May 2 '13 at 6:50

What do you mean by "pace at development?"

If you mean "implemented features per day" it is quite commonon that some features require more effort than others. This is often called the 80-20 rule or the Pareto_principle which claims that 80% of the work/features is done in 20% of the time and the rest (20 % of the work/features) requires 80% of the time.

Usually you start implementing the easy features which is quite motivating. In the end many of the difficuilt tasks had to be done.

share|improve this answer
    
By pace at development I mean 8 hours of working for example. And no I dont start with the easy task and leave the hard task for later. I have always finished the project far earlier from the deadline, but my problem is at the end of the project life time I need to force my self to work for 5hrs, while in the beginning I simply put 10 hours on the project. And leftovers are always small easy task that I know how to solve, but I am not only as enthusiastic as I was at the start of the project and I just want the project to finsih and start a new one. –  mrz May 2 '13 at 6:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.