Software Development Methodology for Solo Programmers and Small Teams
Project Development Roadmap for Freelancers
Overview
1. Inception
2. Elaboration
3. Construction
4. Transition
Beware the Tool Trap
I had been struggling to find any lean software development methodology that can work for solo programmers.
Whenever I researched the topic it was not uncommon to find testimonies like "I held a progress meeting with myself over a one-man burn down chart every morning".
| Quote |
|---|
| I know something's coming. Something big. Like a train, and all I want is to jump on board, but it's getting faster and faster and I'm terrified that I'm gonna miss it. |
| Ryan, Halt and Catch Fire |
Programming motherfucker, cowboy programming are what developers naturally choose when they finally find the time to work on a hobby project that they are enthusiastic about. This of course if you are not the very best expert with lots of stamina will probably lead you to unfinished projects and frustration. Sadly I was never able to fully get the hang of the today popular agile methodologies, no matter how much I tried. So I went back in time to university, where the infamous, traditional Rational Unified Process had been forced down our throats, way before we ever acquired any software development experience. Despite the bad timing, I liked it. This gave me the first insight to what is going on in an office. Several years ago this thread of thoughts led me to Agile Unified Process (AUP) and started to use it in my solo projects.
| Tip |
|---|
| If nobody supervises you, you have to supervise yourself. |
Time flew, things changed, books were read, experience were gained and I found myself using a reduced, lean, flexible and completely raped version of AUP.
Now, the time has finally came to armor myself with a guide on this development process.
I am not an expert on the topic, I just outline a practical roadmap that works better for me, than anything else I tried before.
- If you do not enjoy autonomy on what project you do and how you do your project, it is not for you. I mean you should not be a slave in a master-slave relationship with any person or company, you should at least be a partner.
-"I give you $1,000 to build this website for me." - FAP is not for you.
-"I have $1,000, would you like to build a website with me?" - FAP is for you. - If you have more than a couple of people working for you, it is not the best way to go either.
- If you have no experience in the skills your project is expected to be built upon, you would find this method confusing and I do not think is suitable for you.
- The other side of the scale is excluding too. If you are the absolute expert on the field, do not bother with FAP, you have already developed practices those are more suitable for you.
Read: Beware the Tool Trap
| Tip |
|---|
| Are you sharing my obsession with books, TED talks and similar materials? If so, chances are they leave a guilty feeling in you, because you fail to apply the information in practice. The reason is because they are not instantly applicable. You have to apply them at the right time, the right place, in proper context. If you are anything like me and the most important part of your life is when you are working on something you care about, consider forking this repo, cloning its wiki have your own version and improve upon it every time you gain a new insight. And the guilty feeling will evaporate. |