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.

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?


migration rejected from productivity.stackexchange.com Jul 19 at 19:25

This question came from our site for people wanting to improve their personal productivity. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by MichaelT, durron597, Snowman, ratchet freak, gnat Jul 19 at 19:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

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

2 Answers 2

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.

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.

+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

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