The happier you are while working on a project, the more productive you are likely to be, the more likely that you are going to keep the project going, and the more likely that the project is going to go well. This is the principle behind what I am going to call Morale Driven Development(MDD). In MDD, you always work on short term goals - much like most agile processes, but the short term goals you choose are based on what - if accomplished - will make you the most happy, or more specifically - will make you feel good about the project the most.
As I have mentioned in a previous blog post, the projects that I most
like working on are the ones in which I create something for myself. I have only applied MDD to projects of this type. It's not to say that MDD can't be applied to other settings, but just that I haven't tried it. Having said that, being the boss of the project is a definite requirement since you need to be able to prioritize tasks as you see fit.
Given a list of tasks, there are many ways to prioritze them. In my senario, I will reduce tasks to 3 categories. A task can be either a bug, an enhancement, or a
development task. Some people like to do the hardest tasks first, others like to do the easiest first, others just don't prioritize at all, they just work from the top of the list, treating each task as equal. Most people would probably prioritize based on what is the most important. But there are different opinions about what the most important thing is. For example, some think that having a unified framework in place first is the most important, others think that looking good in demos is the most important. With MDD, the most important thing is your own happiness. You prioritize the tasks by how much impact each would make to your happiness.
For bugs, this means picking the most annoying bugs. If you are developing a product for yourself, and you have been using the product yourself regularly, then you know what the annoying bugs are. Getting rid of these bugs will definitely make you happier the next time you use it.
For enhancements, select features that you are going to make use of or see the results of most immediately and most frequently, or to put it another way, features that make a visible impact. Features that are not frequently used or are only applicable to corner cases should be low on your list.
Development tasks can include: refactoring your code, integrating a new development tool or framework, writing tests, etc., basically anything dealing with development that is not directly tied to a bug fix or a feature. For these you want to select the ones that would improve your development experience the most, because being happy developing the product is just as important as being happy using the product. For example, if you have been falling behind in writting tests, then writting the tests could improve your development experience because they help you to feel at ease about making big changes to the code by acting as a safety net. Or if the code quality is worsening, refactoring the code to be more DRY would make both reading the code and making enhancements easier. Having good development tools is very important for making you feel good as well.
If you need to compare task in different categories, you just have to ask yourself, which task(out of 2), if accomplished, would make me happier? And that's it. At the end, tasks are prioritized, and you start working from the top. You can of course reorder the task list as conditions(your feelings) change.
I have found that in general, a responsive system makes you happy. Why? My theory is that responsiveness makes the user feel more in control, and being in control makes people happy. This principle applies to both the user experience and the developer experience.
Making your UI responsive makes a big difference in your user experience, so it should be high in your priority list. For example, a good trick to use is to displaying animation when you are waiting on computation or network communication to finish, because visual feedback conveys to the user that the system is alive eventhough it hasn't finished its job. In general, the most important principle to keep in mind is to always give immediate visual feedback to the user after he takes any action.
In case of development, for example, ruby on rails makes me happy because codes changes take effect immediately when you hit save, there's no compile or deploy step the feedback cycle is fast. Working with GWT makes me depressed because after every code change, I have to restart the hosted browser, which could take in some case an entire minute to start up, or alternatively compile the Java code into Javascript, which could take even longer(in some cases half an hour!).
As a case study, I will use my work on this wiki/blog as an example. I worked long and hard to get the wiki to a working stage, but the code quality wasn't good and I hadn't written any tests. It was kinda usable but there were bugs, some of which were hard to fix, but I was reluctant to make big changes to it to fix them because I didn't have any tests. Also, the wiki looked quite hideous at the time, and I hadn't bothered to do anything about it because I thought it had a somewhat low priority - presentation should be separate from design, after all, right? But as time went on, the hideousness of the site nagged me more, and I felt worse and worse about the project. At one point I considered abandoning it and just use an open source blog tool like wordpress. But then one day I decided to applied the principle: do the thing that makes me feel good the most. I re-did the layout and fonts of the site, used just a little bit of graphics, it now looks much better than before, and it really made me feel better about this project, which fueled me to keep making improvements to it. Because of the improvements in the look and feel of the site, I made posts a lot more frequently, which also drove development on it. I have written tests for the project now and had made lots of bug fixes and enhancements since then, and feel good about the progress of the project. I would say that this was a case when MDD really made a dramatic difference in the outcome.