Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Suppose you have to develop a medium+ sized software, fully on your own. Like if it was a personal project you want to accomplish.

What methodologies/tools would you use to define what needs to be developed, learned and have a global idea of what the system is as well in its details?

Basically to keep yourself in track and not get lost on the way.

share|improve this question

closed as off-topic by GlenH7, MichaelT, gnat, Bart van Ingen Schenau, Tulains Córdova Feb 1 '15 at 16:45

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – GlenH7, Community, Tulains Córdova
If this question can be reworded to fit the rules in the help center, please edit the question.

Pencil, paper and my brain. Having a whiteboard helps. Seriously, a great deal of my design work happens right in the IDE. Do you have a specific question, based on a problem you are currently facing? It would help us answer the question if we knew specifically what problem you are trying to solve. – Robert Harvey Sep 29 '11 at 0:19
@RobertHarvey haha It's very true. Well, sort of. I'm developing an idea I had, personal project. It's just the software happens to be larger then I imagined and there are things I'll still have to learn how it works and just then figure out how to develop that. – Cassio Sep 29 '11 at 0:24
@RobertHarvey The main problems are probably lack of brainstorming on the details, keeping track on what needs to be done and a view on the system as a whole. – Cassio Sep 29 '11 at 0:25
I'm 99.9% certain that we have this covered in another question or two, but I can't find them at the moment. – Adam Lear Sep 29 '11 at 0:25
I always try to get lost on the way. It's a fast path to learning. – Joel Etherton Sep 29 '11 at 0:30

Usually I just use Mercurial, if I want a feature I just add it and if I don't want it anymore I just remove it. Also, I try to write my commit comments well so I don't get lost.

share|improve this answer
Yup - Mercurial is one of those tools which feel like they were made by Apple :) Simple yet powerful, beautiful yet useful ... – Rook Sep 30 '11 at 16:27

It may easily grow beyond the reach of your attention. Not the span, the breadth.

It's hard to consider too many elements at once.

And then... it becomes a regression rollercoaster.
Everything you do breaks previous things, and rolling back doesn't help.

To avoid that you should aggressively test for regression.
Automatically. (You can't do that otherwise and stay sane)

Testing will add a tough strain to your energies.

If the project is all about UI... you're probably toast:

  • UI testing is hard.
  • Automated UI testing is... still hard.

Untested last minute idea for UI focused projects
Enroll a relative with spare time and a fondness of clicking his mouse as a UI tester.
I'm thinking "teenager" here.

Other issues:

  • It will take forever.
  • You will confront writer's block.
    (It doesn't actually exists as a condition, it's a popular mislabel people attach to their lack of discipline)

If you're used to and love some kind of version control, use it.
Starting to learn one now will distract you.

Graphing out you ideas, as already pointed out, may help.

I've used Freemind, CMaps, XMind, yEd, graphviz, and… something else.

XMind is the less pointless:

  • very fast to insert the data into
  • automatic layouts
  • stricly trying to make you stay on topic
  • very good for taking notes during a lesson (I so wish I had it in college)
  • still hard to use while making your mind up about something you haven't clear there.

A pencil and a notebook still score pretty good on my top ten:

  • I scan many of my notes
  • I make many little explicative drawings.

    • (If you think with images you may never find a fulfilling brainstorming tool)

As a last resort, you can always prepare powerpoints for your own consumption :)

share|improve this answer
+1 for pencil and notebook. – Christopher Mahan Sep 30 '11 at 2:40
+1. However, do you have any suggestions on the "making your mind up about something you haven't clear there" thing? – Cassio Sep 30 '11 at 13:28
@Cassio I do switch back and forth between xmind and pencil + sketchbook, make pointed lists in libreoffice, write down examples and test some approximate implementation. It's a pretty time-consuming process, but you have to scrap away some improductive line of thought to get to something that feels right. (PS: crumpling paper before tossing it is cathartic) – ZJR Sep 30 '11 at 15:11
@ZJR Indeed. Sometimes I was just afraid of writing stuff I didn't need and wasting time on it, but now I see that it's how the process works. Initially we write some useless stuff but we improve with time. :) Thanks! – Cassio Oct 2 '11 at 13:07

Literate Programming.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

If you're writing a paper (or book or report or document) about your project, then you tend to stay on task.

Start with an outline of what you're doing: use case overview, release 1, release 2, release n. Write down an summary of the use cases. Prioritize them. Get them into sprints and releases.

Each release has a use case view, logical view, processing view, component view, deployment view. For the sprint, detail the use cases. Publish the HTML document to show what you're going to do. After detailing the use cases for the sprint, write the logical model. Write code to support this. Write the processing documentation. Write code to support it. Create modules. Write the component view documentation. Write the tests and supporting documentation. Publish the sprint results as an HTML document.

Repeat for each sprint. Review and edit your document from time to time.

There are lots and lots of literate programming tools. They can help you produce a source that creates the documentation and the code both from a single text.

I use sphinx and PyLit but that's because I'm a Python programmer.

share|improve this answer
Good to crunch a university paper out of it and then forget about it, bad if planning to release or mantain the product afterwards. Everybody everywhere should anyway use doxygen, even on python. But that's just because I'm a fan :) – ZJR Sep 30 '11 at 1:33

If you want to write down your ideas you could use a mind mapping tool such as XMind or FreeMind. Both tools are free (for individuals for XMind), and they are great when brainstorming and organizing your ideas. The thing about these tools is just that you have less chances to forget something.

I personally used Freemind before starting my last personal project. I had no particular methodology per se. I just laid out my ideas during one hour sessions once per two days. I think that spacing the brainstorming sessions helped me better see what was wrong, what was non-essential but could be useful in subsequent versions, etc.

On my first code commit I also saved the brainstorming file in the source code repository (I used bitbucket) and kept it up-to-date with my newest ideas.

share|improve this answer
Very good. I'm already testing all of these. Thanks! – Cassio Sep 30 '11 at 13:30

Treat it like a real software project (because it is one). There are only a few things that change because the number of developers is one. You still need source control. You still need a way to organize features to be added an bugs to fix. You still need automated test to check that you don't create regressions in the code. You should also have an automatic way to compile the code (if necessary), run the tests and view the reports.

I am working on a personal project just like you described. I'm using Git, Redmine, JUnit, and Jenkins to satisfy all the categories I described. My work flow is:

  • Pick a ticket to work on
  • Branch the code base
  • Develop code and tests for the task (commit changes to the branch at good save points)
  • Merge branch back to trunk
  • Verify that the build was successful, the tests passed and there were no other issues
  • Repeat

Keeping everything managed and organized is just as important as when there are many developers. With many developers, you need to organization so information is spread to everyone. When it is just you, you already have all the information, but remembering every part of the system is hard. A managed system makes it easier on you and you can focus on the task at hand.

share|improve this answer


  • Control Version System (even if if you the only developer in your garage or home personal P.C.): GIT, Mercurial, Tourtoise

  • Editor with source code highlight, even if you have an I.D.E. (Scintilla, Vim, Notepad)

  • Real world blackboard, whiteboard, some stuff just doesn't fit in your Designer Tools Application.

  • Design Tool: Rational Rose, Umbrello, (U.M.L., E-R,) Visio, or "Poor Developer's Designer Tools" like Power Point, Corel Draw, Open Office Draw

  • Text / Source Code Text comparison tool, e.g. WinMerge

share|improve this answer
Very helpful! I'm putting all these to practice. Thanks. – Cassio Oct 2 '11 at 13:04

It depends on how you can distinguish and handle different tasks, because you'll need to take a look on every single step of the development process. ... I think tools are only useful if you already know how to use them and one of the worst mistakes is learn how a tool works rather than learn what to do with it. (I hope it was a bit clearly)

First, in my opinion, you have to write down what you expect the software will do and specially what it won't do. That's a crucial point. The next step is divide the final system into lower subsystems, making the building process easier. And last but not least you'll need to choose your tools. Basically a good IDE, a VCS and a data modeler. You can add a lot of other tools to help, but care to don't start wrongly.

Well, the beggining seems not so attractive, but the process will become fun along the time.

share|improve this answer
Great one! Thanks Lucas. – Cassio Oct 2 '11 at 13:03
Yeah! Remember that code is -if the project is well designed- a small part of the whole. – Lucas Maus Oct 4 '11 at 14:16

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