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.

[Edit]

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.

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.