I've just started a programming job where I'm applying my 'How to code' knowledge to what I'm being taught of 'How to Program' (They are different!). As part of this, I've been taught how to capture requirements from clients before starting a new project. But...

How do I do this for a nebulous personal project?

I say nebulous, as I often find halfway through programming something, I want to expand what my program will do, or alter the result. Eventually, I'm tangled in code and have to restart. This can be frustrating and off-putting. Conversely, when given a fixed task and fixed requirements, it's much easier to dig in and get it done.

At work I might be told "Today/This week you need to add XYZ to program 1" That is easy to do. At home (for fun) I want to make, say, a program that creates arbitrary lists. It's a very generic task. How do I start with that? I don't need it to do anything, but I want it to do something.

So how do I plan a personal programming project?

Related: What to plan before starting development on a project?

  • I am having a little trouble interpreting your question. It sounds like there is a change in the level of what you do at work from coder with a lot of direction to developer with more independence? For your personal projects, you are finding problems with let's call it architectural failure where something breaks as you are expanding your scope? Sep 2, 2012 at 14:54
  • 1
    At work I might be told "Today/This week you need to add XYZ to program 1" That is easy to do. At home for fun I want to make say a program that creates arbitrary lists. It's a very generic task. How do I start with that? I don't need it to do anything, but I want it to do something. Sep 2, 2012 at 15:00
  • 1
    You hit on a good point. When someone else decides and describes, the hard part is done. It seems like this now. I think writers call it the terror of the blank page. As you get more projects under your belt, that freedom will be less intimidating and the relationship will invert and you will appreciate the gift of the blank page. It will be easier to run with the why and make decisions based on a pool of past experience. Sep 2, 2012 at 16:03
  • 1
    Something that helps me in my simple pet projects: first I write pseudocode without caring for APIs, etc. Then I strive to make sure I don't change much the pseudocode I've written. This way I stop the impulse to add unnecessary functionality and to include extra complexity layers.
    – K.Steff
    Sep 3, 2012 at 3:46

3 Answers 3


There is nothing wrong with what you are doing if your purpose is to learn. Many developers leave a string of half-written applications behind them when they had finished everything interesting in them.

However, if you want to write something and finish it, pick a problem you want solved then do the minimum you need to solve it. Use existing libraries and code examples and hack it together. Once you have something working then go back and clean it up and expand it.


If you are looking for inspiration, there are lots of places to start. Microsoft has the coding 4 fun site. There are thousands of open source applications out there that need fixes, improvements, automated tests and documentation on sites like github.com and codeplex.com. Reading other people's code also helps you learn new techniques and libraries.

  • Thanks. I hadn't known about coding for fun, but it sure does look fun. Sep 2, 2012 at 16:09

Congratulations on your expanding role. Requirements elicitation and requirements management are two great skills for developers. Sometimes these roles are entirely controlled by product managers outside the development organization and the result can be very limiting.

Architecting software for ease of expansion and maintenance has profound impact on everything we do. In a paper called "On the Criteria To Be Used in Decomposing Systems into Modules", D.L. Parnas implemented a project twice, once with functional decomposition and once with data oriented decomposition. Then he added some new features and took metrics about the impact on the code. The main take away was that the two methods had very different properties for changeability, independent development, and comprehensibility.

Later work published by Parnas as a case study of the A-7E Avionics System and it use of encapsulation, information hiding, and essentially proto-object oriented design was very influential on object oriented programming languages and later analysis and design. It is also documented in the book "Software Architecture in Practice" by Bass, Clements, and Kazman.

You mention that your code gets tangled up as you expand the scope of your personal projects. Consider using the following to help keep it on track:

  • Are you using an object oriented where the code is implemented as classes? This approach is powerful in terms of promoting maintainability and reusability of code.
  • How big are your classes? A big class that does many things can often be had to maintain. If you can make each class do one thing well (a technique called separation of concerns), it is usually easier to implement and test.
  • Are you using unit testing or test driven development (TDD)? If you create tests that verify your code works, then with each iteration or increment, you can verify that it still works.
  • Are you using Git or some other source control tool? Using a tool to lock in your changes at the end of each cycle of modifications and testing (usually scoped to one day or less) can give you (and others on your team) a safety net. Having the code revisions saved can let you back out changes, but more importantly, it can help you enumerate what you changed between when it worked and when it broke. Usually one of those changes can be changed again to get back to a working state.
  • Are you using iterative/incremental approaches? You can read about these approaches from on this page by Alistair Cockburn who writes extensively about Agile development. Wikipedia also has a nice description.

Hope this helps. I am sure your question will elicit a great variety of helpful responses here on Stack Exchange.


I agree with akton.

If you are trying to create a working product. Define it, design it and then code it.

Jeff Attwood wrote a blog about KISS and YAGNI.

Look into Test Driven Development to avoid scrapping projects and restarting from scratch. If your app passes all your tests, you can refactor parts of the code that you don't like. Red, Green, Refactor.

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