As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened,
visit the help center for guidance.
Closed 7 years ago.
What are some solo developer programming methodologies for smaller projects?
Just about any development methodology will work in a solo environment except for those that explicitly require a team (such as side-by-side programming). But even then you could get around that by just creating some imaginary friends/teammates or developing a multiple personality disorder.
Even as a solo developer you can use methodologies applied to large development teams.
- Write a Spec.
- Layout a UML.
- Do pencil-and-paper UI design.
- Hallway testing: If your expect a large crowd, ask Mom if it's easy to use.
- Peer review: You can build ad-hoc review teams with other solo developers.
- Keep an up to date schedule.
- and so on...
I solo develop all the time, and these practices keep me in line with my own work and give my bosses a great resource to know what I've done and how far along I am. And they keep me on track, to boot!
The rubber duck methodology comes to mind:
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
Many agile techniques work great solo:
- User interviews and stories: If you don't know what your users want, why would your software be useful?
- A simple spec: Or even just be a mission statement. "Let people broadcast short messages to their subscriber lists." "Use in-degree to sort internet search results." "Let people collaboratively answer programming questions." Whatever.
- A strictly-ordered todo list: Helpful to keep you from drowning in thoughts.
- Tangents log: A good to-do list has a "to-don't" component, so you don't obsess over things you aren't going to do (yet).
- YAGNI: Stay on target. This is very important when working by yourself, because no one is there to tell you "No! Don't reinvent dynamic typing in Java! Get back to the project." To-don't lists help with this.
- Test-driven development: Writing tests forces you to think about the end result, rather than getting bogged down in implementation details. You'll get bogged down enough anyway; no need to make it worse.
- Frequent releases: Make yourself stick to deadlines. "We'll have a feature-complete version that includes user stories 1-4 by Friday. It won't connect to the network or save data to disk, but XYZ..."
- User testing: Have your buddies look at what you're making on a decently frequent schedule -- maybe once a month, maybe every week, depending on how many friends you have and how much beer/pizza you want to feed them. Pay very close attention to what they say and do and think when using the software.
And other things that only seem like they make sense in big projects can help a lot:
- Source control: Install git. It's bone simple. Use it. Don't obsess over it.
- Off-site backups: Y'know. In case of house fires or floods.
- A blog: But you're only allowed to write there when a release comes out. ;) Also helps you build an audience for your product before it even ships.
Hope this helps! Solo programming on a large project can be very daunting.
Follow what is laid out in this Stack Overflow question:
What Tools/Techniques can benefit a solo developer?
Also. Use Source Control. You wouldn't believe how many times I've been bitten by that on personal projects.
There's this:
http://en.wikipedia.org/wiki/Personal_Software_Process
It's probably overkill
The issue is more a question of what you are comfortable with and what problems you hope to solve. Most methodologies are used by a solo developer at some point (pair programming is a notable exception). The issue is are you actually alone, or just working by yourself? I have found that it is invaluable to have people I can bounce ideas off of. Furthermore having someone else to look at you code (peer review) is a great way to find issues that you just cannot "see". So to agree with Aiden Bell "Programming on your oen is uncool."
I would try and connect to a community (like SO) where you can bounce ideas off of others. Then you need to build your methodology in such a way as to allow for interruptions when you send an idea out.
Does that make sense? Why are you programming alone?
Pat O
Not really an official methodology, but I have done a lot of solo development (independent consultant and ISV), and here are the things I have found to be important:
- Find an online organization (like
oisv.com) to share thoughts and
ideas
- Make sure you take time to interact
with actual people in the real world
- Set project goals, deadlines, and
milestones
- Take time to do appropriate up-front
design and project planning
- Set aside working hours are stick to
them
- Don't work too much and burn yourself
out
- Nothing is ever perfect, so strive
for good code that works, not
perfection
- Get some non-programming hobbies
This is more of trick than a methodology. When you're debugging, explain the bugs out loud to yourself as though you were trying to explain it to a co-worker. It feels silly, but forcing yourself to articulate the problem out loud often reveals what the problem is.
