23

Every once in a while (read: about every day) I come up with a new idea, start a new project in my favorite editor/IDE, start coding and the next day I delete it and start something new. I've been programming for about six years now and in those six years I have only really completed one very small project (a Dashboard widget for Pastebin.com). Though this might be great for learning coding, I really want to complete something.

What are some things I should do before, while and after the actual coding? What are good resources that teach me how to organize such one-man projects?

If it matters, I want to do web or Mac development.

Improve this question
2
  • 8
    From what you posted, it doesn't sound like a lack of organization. Instead, it sounds like a lack of interest or drive to complete the project. Is there a reason why you delete the projects instead of following through with them? If you truly aren't interested in the project or the technologies you are using, there's really no point in following through, or else it will become a chore.
    – Thomas Owens ♦
    Aug 3, 2011 at 1:17
  • 1
    @Thomas Owens well the main reason I delete unfinished projects is because they make my programming folder look messy (i.e. contains files I'll never use again). I'm very interested in the technologies, I guess it's just that lack of motivation then.
    – user4595
    Aug 3, 2011 at 3:40

6 Answers 6

Reset to default
17

I think the real problem, long-term, is motivation, rather than organization.

  1. Find users and talk to them. View your project as a sort of gift (or sell-able product) to those people. (Someone to bounce ideas off of is also great, even if they don't actually develop code with you.)

    Having that social motivation is going to be vastly more powerful at keeping the project interesting in the long run than mere personal curiosity.

  2. Your goal should be small bite-sized chunks of useful functionality. Put it up on SourceForge or GitHub, and treat the project as something that needs a chance of survival even if you are suddenly hit by a meteor.

    This leads to more releases (meaning more feedback and enthusiasm from users) and also greater likelihood that another person might decide to contribute to the project.

  3. Pick a specific learning goal for yourself. What technology or technique does the project help you learn? If it turns out the technique isn't suitable to the problem-area, will you be interested enough to at least finish version 1.0 before putting it aside?

    Examples of such goals include writing parsers, network protocols, aspects of game AI, learning frameworks or toolkits, a new language, etc.

The worst-case scenario means missing all three, where you repeatedly do a "massive rewrite" of a never-released tool involving code you don't find interesting for people you aren't sure exist.

Improve this answer
2
  • 2
    +1 for the "if you are suddenly hit by a meteor.". No, seriously, excellent tips against procrastination.
    – Randolf Rincón Fadul
    Aug 3, 2011 at 2:02
  • One thing to add after the benefit of experience: If you want help, you will probably need to promote your open-source project if you don't want to stay the sole developer. "If you build it, they will come" is very unreliable.
    – Darien
    Feb 12, 2014 at 23:16
2

When you come up with an idea for a new project while working on a project, just note it on a list of project ideas. Then get back to the current project. If the project is worthwhile don't let yourself get distracted by a new project. Use the following steps only if it is an outstanding idea.

Before you start our project, plan it out. What will it do? How hard will it be to do? What are the knowns and an unknowns? What is likely to go wrong? How long will it take? [Now you can decide whether to go ahead or stop now.] Keep your plan. [If you are working on a project, put aside the new project and get on with the other original project.]

When you start your project set it up as a separate project in your IDE. (So you don't need to delete it to start your next project.) Check it in to some version control software as a new project. (Now you can delete it if you find it getting in the way of another project.) Check in your project whenever you have it doing something correctly. (Now you can go back if you get off track.)

Track the issues that come up on your project. This can be done with a few text files withing the project. Files like TODO, Changelog, README (can include known bugs and issues) might be appropriate.

When you get your code working tag it in your version control. If its worth sharing do so.

Go back to your plan and see how well you did. Do a lessons learned document for yourself. What did you learn, how well did you estimate? What problems did you miss? What problems did you overestimate? Anything else you deem important.

When you abandon a project, do the lessons learned process. Add a note about why you abandoned the project.

Review your lessons learned once a month or so. As time goes on you can increase the interval between reviews.

Improve this answer
2

Here's a link to "Doing Agile in a team of one". It's an interesting read!

Also, you might want to consider why the disciplines of software dev we do "at work" are important. Are they only important if there's 10 people in the team? No, they're important because they help you think about your project.

Who is your target audience? (If it's you, then great - but remember what you originally wanted the app for)

If you're doing a UI, think about your audience's needs, then do some mock ups before going into hard core UI development.

If you're looking at your business logic, try TDD or BDD. Think about how you want your app to work before attacking it. Consider wrapping it in a harness such as Fitnesse or similar. If you want to test your app, the easiest place to start is at the start.

Improve this answer
1

Given your comment, stop deleting your projects!

I typically don't keep projects that I'm not actively developing (or foresee actively developing in the near future) on my computer, but the source files do exist in an SVN repository and everything (including IDE config files) is backed up on an external HDD. It doesn't answer your questiStop deleting your work, and focus on motivating yourself.

If you are looking for a hosted repository, look at Google Code, SourceForge, GitHub, and BitBucket. Upload your files, keep them somewhere, and when you have a renewed interest, pull them down. Although you can make them private, you can make them public if you aren't ashamed of them. Perhaps someone will be interested in restarting your work or learn from your examples (especially if you are using an interesting library or framework).

Over time, work on your motivation. Try to focus on one thing at a time. You might not get your code to production quality, but perhaps you can get it to example quality, or something that other people can look at to see your skill set, knowledge, or to learn about a particular way of doing things.

Improve this answer
1

First of all, there are projects and projects. If you try out some technology or library, or sth else, you probably create a project in your IDE, find out if this thing is interesting to you or not, and then delete your project. That's ok, everybody does this.

Another type of project is real software/sites/etc., which is business, where those 'projects', files, programs are just tools, and developing such complex things requires motivation and the goals:

  • what you develop (web site/text editor/mobile app/...)
  • what do you need it for (make money, pick up some new technology/contribute to open source/...)
  • when would you do (how much time you devote your project, how long are you planning to do that)

What you develop should be new. If you want to make just another text editor because you think some feature you demand is missing, you probably don't need to do that. There are hundreds of open source tools, contribute to one of them.

Even if you make a small single-use tool like a script, you should state those things listed, it would be easier to solve the problem itself.

If you are stuck at writing code (e.g., massively rewrite your code) you are probably not experienced enough to do that. Take a good book on software engineering, your platform (mac/web/etc), read code written by more experienced developers that does similar things. There lots of places to do that now (github, google code, programming blogs, stackoverflow).

Don't try to solve a very complex problem (e.g. writer a compiler or an operating system) from scratch, first decompose it to smaller tasks, mostly often, someone has already created libraries that help you solve your problem.

Improve this answer
0

Have you considered asking a loved one what they really need for a webtool, and then actually make it for him or her?

This should provide the motivation to actually finish and deliver which is the hard part in this. Also you get the benefit of supporting and maintaining the application if it is useful to your loved one. If it is not useful, you can learn from the experience what can go wrong.

Improve this answer