I’ve embarked on a side project to develop an event scheduler without much planning, but every good software project needs a methodology. Since no methodology I know really suits what I’m doing, and because the world of software really needs yet another methodology, I’ll share mine here.
This methodology will be called the Loneman’s Coder Methodology in the spirit of the rugged pioneers of coding. The basic idea of this is that I’m working alone and not with a team, so my way of working should be adapted to this reality. I can leverage the power of the Internet to find solutions to my problems, but there is no other person than me that can deal with it. Also, I’m working on a product and not a project for a single client: I’m the one making the call about which features needs to go in the product.
So, to prepare for my coding journey, I’ll be going through the following steps to maximize my chance of technical success and waste as little time as possible:
- Defining the quest: To go somewhere meaningful, you need to have a clear idea of where you’re going so you’re not wandering aimlessly around. In my case, I already defined my quest: I want to build event scheduling software for conferences.
- Painting a pretty picture: To make your path even clearer, you should mock the important parts of your product so you have something to work from. In you head, everything may fit correctly, but reality has a way of foiling expectations. It’s better to find out from a mockup that your concept is impossible than from a few weeks of coding the UI. You can check out the mockup I did for my own product in the post defining my project.
- Testing the moving parts: You should prototypes the parts that you are not sure about and that are vital to your product so you don’t fall in the Pits of Technical Risk just when you were starting to get somewhere. This may be an unnecessary step if you’re already familiar with every technology and pattern you’re planning on using, but for most projects there is a least one or two thing really worth testing. That way, you can start coding at full speed later without having to worry too much about what’s lurking in the corner. I already wrote about the prototypes I planned in my previous blog post.
- Writing a map: You need to map out what is needed to get your product to a usable state. Each task or feature should be kept small so you can complete it fast and keep the momentum going, especially if you’re working on this in your spare time like me. I’ll start planning my tasks when I’m done prototyping since I’ll have a better idea what needs to be done and how long it will probably take.
When everything is ready, I’ll finally be able to jump into it and build the real thing. For now, I’ll be starting with the following guidelines. Since I have not reached this part of the project yet, I’ll have to make sure this evolves as I learn new things.
- Crank out the code: This is where you put your nose to the grindstone and do the real work of writing the code for a small feature on your map. Since all the parts in the map should be important for the final product, you should work on the task that’s best suited to your current energy level and motivation to optimize your efforts.
- Journal your journey: I don’t believe in zero documentation. Having just enough documentation so you can remember why you did something can be very useful, especially for a project that’s worked on in small units of spare time stretched out over a long period. Since you’re working alone, you won’t have a team to help you remember, so anything you don’t remember and didn’t document is be lost forever. It doesn’t need to be long and boring: for my project, the documentation will mostly be blog posts like this one.
- Focusing on workmanship: Each feature should be complete in itself and work without breaking anything else. What you’ll be making here is only the start, so you need to make sure you reach the end of the road with good, maintainable code. It’s better to have a few features that works well and that are properly documented than a few half-baked things that will break the first time a user tries something a bit different than what you planned.
After all of this is done, I’ll hopefully be able to ride into the sunset with a good software product that’s in a usable state. This will only be the beginning of the rest of the life of the software: the quest for users will start and the software will need to be maintained, which is a completely different game. Sign up to my newsletter to stay tuned until then, there are still a lot of steps to complete!
| Reference: | Getting started with the Loneman’s Coder Methodology from our WCG partner Cindy Potvin at the Web, Mobile and Android Programming blog. |
