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.

I am a hobbyist programmer, and I've started many medium - sized projects to work on just by myself. These include games, a raytracer, physics simulations etc.

By the time these projects get to a certain size (around 5000 lines), I begin to slow down in adding features to the program. This is not because of a lack of ideas of what to implement in a program, but rather a struggle in how to go about it. In particular, I'm afraid of breaking what I already have working in order to implement a new feature.

I've tried using version control like Git and Subversion, but these seem unnecessary when you are a one man team. I simply have a folder of "versions" of my program, one for each major change I make.

How do I keep coding past this 5000 line mark? What about the 50000 line mark?

share|improve this question

migrated from productivity.stackexchange.com Jun 10 '14 at 19:13

This question came from our site for people wanting to improve their personal productivity.

Do you know what coupling, cohesion, and TDD is? –  Bunyk Jun 10 '14 at 9:44
I have a story similar to yours with pet-projects I do at home as a hobby. The most paralyzing sensation is not being sure of what use the "system" will have when it's "ready". I mean, everything "can" be done if you really want to, but is it really necessary, or is it really the RIGHT thing to do? So my advice is: choose something you fell will make a difference to someone, even if this someone is only you. Of course, if you work as a developer, applying every best-practice imagineable is the best exercise you can get. –  heltonbiker Jun 10 '14 at 19:21
Versioning by folders works (sorta) if you don't care about the differences between the versions. I used to have the same loss of interest, but decided to try using git with my own projects after using svn at work. Now, knowing what changes I have made (by diff and log) and the ability to branch and merge have removed most (but not all!) of that mental barrier. Thing is, it took a month or two before I got used to using version control by myself and not on a team. How long did you try it? –  Izkata Jun 11 '14 at 0:50
Find a local Agile/TDD group and ask them to show you how modern automated refactoring works (ReSharper + Visual Studio or IntelliJ IDEA). Understand SOLID. –  Den Jun 11 '14 at 11:20
Source control is vital, even for a one man project. Without source control, you can't revert easily. If you can't revert easily, you can't make changes without worrying about breaking it. Source control means you can experiment without having to mentally keep track of everything you've done. –  Phoshi Jun 11 '14 at 11:40

3 Answers 3

up vote 21 down vote accepted

First off, version control is NEVER unnecessary in a one-man setting. If you write anything beyond 100-500 LOC and intend to work on it in the future, do NOT shy away from using version control.

Second, write tests. Tests are the only way to add or change code without the fear of breaking anything.

Third, document as much as you can. Not just the code but also other artifacts. For example having an issue tracker is also part of documentation and a one-man team is by no means exempted from maintaining it.

If you can, open-source it so more people can get interested about what you're building.

Lastly, the best way to learn to manage large code-bases is to take a plunge into one. Just start READING any open-source non-trivial software -- nothing can make you more proficient programmer than reading other people's code.

share|improve this answer
I'd like to amend: 2) there are several types of automated tests (unit-, behaviour-driven, GUI-tests). Think/read about which one makes sense to your projects. 3) document the main aspects of the architecture, e.g. arc42 is a very slim template. –  Andy Jun 11 '14 at 14:12
Version control is trivially easy to use these days for huge benefits. If you can't remember every LOC you've ever changed on a project, you should be using version control for it. +1 here on test & document too. –  jb510 Jun 12 '14 at 22:36
What large code bases would you suggest browsing? –  user3487347 Jun 13 '14 at 6:19
Depends on what language you know. For C, Redis or Git or mod_wsgi. For Java Neo4j, for C++ ZMQ, for Python Tornado or Gevent or Pyramid. –  treecoder Jun 14 '14 at 6:04

I worked on a large project with 5 million + lines of code with 23 separate teams and ~250 people (developers and managers) where all the code was brought together into a monolithic build. The key was to continue decomposing parts into new teams/projects, creating clear interfaces, and creating meaningful abstractions. The most important part was the abstraction concept.

Think of a car. It doesn't really matter what type of car. There is a general idea of a car. Someone/team made the tires, the engine, the brakes, etc... Each of these items can also be an abstraction where you continue to decompose the the parts into other meaningful abstractions. This is basically a top-down approach to design. You're trying to create high level, manageable pieces and to have an understanding of what you're building before you start. Where this approach goes wrong is in trying to make/decompose the whole system before you start anything at all (analysis paralysis).

What you're doing is a bottom-up approach, where you start building and wait for the overall design to emerge. Most of us developers love bottom up because we get to start coding right away. Where I think you're finding the difficulty is in "seeing the forest from the trees", where it's hard to visualize the proper abstractions and how other pieces will fit together. That's why you are "afraid of breaking what I already have working in order to implement a new feature". You haven't thought enough about the whole before you started. This is where bottom up process seems to run into problems and, in my experience, leads to a bowl full of agile spaghetti.

Using the car as the example, you have made the tires, but now you're afraid to add the brakes because you're not sure how it will fit within the overall car.

The sweet spot is somewhere in the middle of these two approaches (i.e. you should use both). It's impossible to be fully top-down because you can't know what something looks like until you create it, so thinking you can decompose a system fully in this way is folly. Bottom-up has problems too because it leads to meandering through a project, poor early design choices, and generally poor interfaces. What I have found is that you start with the top-down as a guide to create abstractions and then use the bottom-up to build out on each abstraction. If you have the abstractions then you will be thinking about how they all fit together as you code.

share|improve this answer
+1. One possible way to get this middle approach is to think/design top-down, and code bottom-up. Then you can code deepest, more elementary components first (those without dependencies), and then going up taking advantage of encapsulation and higher-level interfaces to keep complexity tractable on each layer. –  heltonbiker Jun 11 '14 at 2:42

This is normal. The more complex the software gets the larger the chance of 'breaking what I already have working in order to implement a new feature'.

It is good that you realize that. Now you need tools to help you manage further development, because after a certain program size and age you are no longer able to keep it all in your head. You will also realize that you need to refactor your code when you add new stuff (new structures required, new insights, etc).

Tool #1 is documentation. This goes two ways:

  • You need to document the current state of the software. This can be done in many ways and is a subject on itself (too broad to discuss here): good self-documenting code, database diagrams, useful code comments, some documents describing what was done (and maybe why), a bug/feature tracking system,...

  • You need to document what changes are to be made to the software before actually doing that. This documentation stage helps you to make an inventory of what needs to be changed how, and can come in many flavours, ranging from agile techniques to old-fashioned functional/technical designs. It helps you reduce the chance of breaking stuff.

How detailed you want to write this documentation is up to you: experiment with techniques and forms that suit you.

share|improve this answer
I'm currently doing this in a BLOG I created only to guide development step by step. I don't even care if someone reads it (by the way it is in portuguese). Besides documentation, the very rationale of "why and how" you design the system is something worth writing about (not only thinking about inside your head). +1 –  heltonbiker Jun 10 '14 at 19:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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