How can I complete a project as a single web developer?

Question

I am a PHP 'developer' who codes for fun. My problem is I have never completed my large projects. Please I would like to know how experienced programmers like you are able to complete projects single-handedly.

My problem is I tend to allow frustration get me. I think this is because I do all of the coding and the graphics alone and this is really challenging for me coming from a country where electricity is epileptic(In Nigeria - You would have to do things quickly, because power will be cut short after certain times that are sometimes unpredictable). So a very picky person like me finds it hard to immediately make design(graphics) decisions.

What am asking from you is a formula that works for you. A formula that gets the work done. Right now, I am thinking of a formula that involves the coding of a 'dirty' prototype of my idea. Then, when am done, I'll just focus on the graphics aspect. Is this really a good idea?

Please I need your advice because I may never get to complete any project of my own.

Note: I have no problem coding with PHP.

Thanks

Answer 1

There are two main challenges I face when I work alone on a project:

1. Time management
2. Featuritis (always trying to add yet another feature)

To overcome both challenges you have to be extremely disciplined and professional.

So:

1. Use an issue tracker. It doesn't matter you are a lone wolf, keep track of everything you do for your project, whether it's a feature or a bug. Make a feature / components list. Mark truly essential components as version 1.0 and all else as version 2.0. And then delete everything that's marked as 2.0.
2. Use a version control system.
3. Use a framework. Focus your efforts only on what you actually have to do.
4. Buy a stopwatch. Code for an hour. Stop and relax for 10-15 minutes. Repeat until you get at least 5 hours of coding each day. Never ever code and design in the same interval.
5. In your issue tracker (or somewhere) write down specific timelines for milestones. Keep them. Better yet, use some project management app.
6. Open source some (or all) parts of your project. If you made some fantastic library, you can release it in the wild and get help from others.
7. Open source your old unfinished projects. There is a (slim) change that someone will step up and finish them.
8. Buy a UPS
9. Create a working environment free of any possible distraction.

Some (or all) of the above are stock advice and apply to everyone not just a lone developer. The main difference is that in your case you have to do all of that (and so many more) without having anyone to help you get back on track if you slip off.

Update

To give you a better idea, check out this project. I wrote it, and it's just 69 lines of code. But it has:

1. Source control,
2. Issue tracker
3. Wiki
4. An ohloh page

The first three are kindly provided by bitbucket. (bb rocks!)

I'm fully aware that the project is probably the least significant piece of code I've wrote the past few years, but there are at least two people nagging me to add mcrypt support already, so all of the above helped in giving me some sense of motive.

Answer 2

Try http://programming-motherfucker.com/. I went back to programming after hours of frustration and get the work done. :D

Answer 3

Never think of a big project as a big project. It's never a big project unless you're a terrible coder who lumps everything into one giant wall of repetitive code with no function calls. It's tons of small projects that happen to share a namespace. Each class, subroutine, function, interface, each one of those things is a project, and each one deserves your full attention. If you try to focus too much on the big picture, it will overwhelm you. Break it down to simple steps, then complete the simple steps in an orderly manner.

Also, never worry about graphical crap. That's the stuff you do when everything is working well, and you have time to step back and do some navel gazing. In the professional world, that wouldn't be your responsibility anyway. So get it running, then work on the graphics. You can rough them out on paper, and then implement them as you can.

Answer 4

Start by defining the project's overall requirements - what functionality is required? Then focus on the interface - draw up some wireframe mockups: http://en.wikipedia.org/wiki/Website_wireframe

...All of this is done with paper and pencil.

Without the "big picture" items flushed out you will be "chasing your tail" trying to retrofit your project, fixing usability problems, and battling scope creep.

Answer 5

Well, I'm not sure there is any one good answer for this. Ultimately, a project is only "finished" when you decide it is.

In order to help you decide that a project is actually finished, you may find it useful to define some requirements for the project to be considered complete.

I'm not certain how familiar you are with this, so please do not take offense if any of these next comments are below your level of expertise.

A typical development environment will undergo some of the following stages

1. Gather requirements such as "The system must allow the user to type in a name and store the name in a database" you can move on to step 2 before you have a full list, but there should be enough to be able to envision a basic system
2. Analyze your requirements, determine how long you think they will take. If any seem like they are too general, or will take longer than a few days to code, you should probably try to break them into smaller requirements.
3. Prioritize your requirements. Determine which requirements need to be in the system in order for it to operate. These should typically be higher priority. Then determine which requirements are more nice to haves. Typically those will be lower priority, but if they have a low time estimate and they keep you interested in the coding for the project, you may consider giving them a higher priority.
4. Once you've determined the minimum requirements to have a working system, set a date, based on your analysis of when you want to complete the core system.
5. Start coding the requirements you selected for your target release date and do your best to complete the system on or before that date.

When you've done this, your project is technically complete. Of course, you will probably want to add those lower priority requirements to your project in the next release, and in all likelihood, you will have come up with some more requirements by then. At that point, you pretty much just repeat the steps above.

It's important to discipline yourself. Try not to add things that you don't have a requirement for until you are ready for the next release.

It certainly helps to be able to work with other developers. If there are people you know who will be using this project you are creating, see if you can get them to help you stay focused and provide encouragement.

The steps indicated are just some simple steps, and are just one of many ways to tackle your issue. You may want to look up Agile development for some excellent ideas.

Answer 6

So, you want to complete your projects, but it sounds like your disincentive from frustration exceeds whatever incentive you have to finish.

Frustration is something that's always an issue in software development. If you always knew how to solve every problem, the time from start to completion would be the time it takes you to type the code. Part of the process of becoming a good programmer (or problem solver more generally) is learning to deal with frustration. Sometimes that means knowing how to step back and look at the problem in a different way, sometimes it means knowing when to step away altogether, and sometimes it means knowing how to get back on the horse that threw you and give it another try.

It'll also help to develop strategies to avoid becoming stuck or frustrated in the first place. Good design helps avoid problems before they occur. Good methodology -- keeping track of tasks and bugs, documenting what you're doing, unit testing, etc. -- help catch problems early and makes sure that you stay on track.

If the first thing you do when you decide to work on a new project is to start typing code, you should start thinking about your development process. Go back and look at your directory full of unfinished projects. Take a few minutes to look at each project so that you remember what you were trying to do and why you stopped, and then write that down in a few paragraphs. When you're done, you'll have a catalog of all your projects and the reasons why you stopped working. You'll probably notice some patterns, like: "I stopped development on this project because I ran into [a major issue], and I couldn't get past that without rewriting a lot of the project." Was that major issue something that you could have predicted if you'd done a better analysis and design before you started coding? Was it something that you could have detected with a quick proof of concept? Nobody here can tell you exactly why your projects are failing, but you've got all the data there waiting for you -- just take an honest look at what you've done so far.

Adding more steps to your development process, like writing a design document, adding unit testing, etc., might not seem like something you want to do when you're just programming for fun. But you're obviously not happy with the kind of progress you're making, and it's a LOT more fun to program when you can eliminate the sources of your frustration and help keep your development going smoothly. It's also a lot more fun to have a list of completed projects than a list of aborted attempts.

It's always easy to start projects, but usually not so easy to finish them. The devil is in the details.

Answer 7

Before I was introduced to Agile, I loved starting a project ...3 months later - I'm bored ...or some difficulty got the better of me and I took a break until I could think of something new to work on.

Since I have begun using TDD, I have learned how to manage my projects in much smaller pieces. I build some scaffolding as I go ...making comments along the way to ensure I can come back later to adapt to new requirements. Since I do a lot of coding on my own, this is a system that simply works for me ...

That said, if you are not familiar with Agile - at the very least TDD - do yourself a favor. Once you get the hang of it, you will be able to see where your large projects bogged you down. Break those large projects into libraries that fulfill specific tasks. This allows me to have successful unit tests; a la, gratification of something completed that motivates me to the next step.