I’ve been a programmer for about 5 years now. I’ve worked on a large variety of projects. Small projects, medium projects, large projects. I’ve worked in teams, I’ve worked alone. I was an employee. I was a freelancer. But from these 5 years, I’ve spent about 1 year – an astonishing 20% – or maybe even more working on projects that were never used. They were paid for. I was paid for my work, but the project was simply cast aside. Nobody used it.

And I’m puzzled, some of those projects were quite expensive, not the average “500 euro for a 5 pages with contact form and Google maps widget website” deals you find when working with freelancers. After months of work and thousands of euros paid…nothing. The project was quietly buried. And I’m not a singular case. I’ve talked to my friends that also work as developers and most of them worked more than once on a project that was never used. Is software so worthless than you can easily cast aside projects that costed so much? It seems it is.

I believe it’s because the clients usually think about huge projects, with thousands of features that will make them the next month’s billionaires, while forgetting that developing projects of that magnitude usually take months or sometimes years to be implemented and by the time it’s ready, might not worth a dime and it would be cheaper to simply throw it away than continue pumping money into it.

Imagine a project that was started 18 months ago and and was initially scheduled to be released in 24 months. Let’s say that this project was meant to be “the next big thing” in real-estate with all the possible features, with anything a real-estate agent’s heart could ever desire. Would be in production today? I seriously doubt that. Nowadays, the only way you can become a real-estate millionaire is to start as a real-estate billionaire. And why would anyone pump money in that? The market moves so quickly, that this year’s niche could be full of competitors next year.

The solution: start small. Build a large project in small incremental steps. Use agile development methodology. Be ready to change the specs at any time. Build the project as modularised as possible. Make sure that you can easily add new stuff and remove worthless stuff. Have a look over MVC, it allows a more agile approach on web projects.

And of course, always ask yourself: what would Captain Picard do?

At one time in our careers, we all worked as freelancers. It’s fun, you get to pick your work, no annoying project managers, no accounts managers, no managers at all. You’re your own boss. Just you and the project. And yeah, almost forgot, the client.

Because most freelancers are cowboy programmers that work from home, sooner or later the project will fall behind schedule. Reasons include proximity to the fridge (also has a devastating effect on the waist), games that are installed on that computer, movies and so on. What do you think most people will choose between eating a huge sandwich and drinking some beer while watching the new episode of Heroes and working? Yeah, my point exactly.

And when you’re behind schedule and the client asks you for a status update, you’ll do what every other moral person would. Lie about it! But try to do it with style and in a way that won’t get you caught. Most common lies are:

• “I’ve worked on the database” since nobody can actually check that
• “I’ve solved some security issues” again, really hard for somebody to actually check that
• “We have a small problem with the server’s configuration, I’m working on it now” somehow implies that is not your fault
• “I haven’t done the layout part yet, but everything else is ready” but I can’t show it to you without the layout now, can I?
• “My (retarded) neighbour flooded me, but don’t worry, your files are safe” should work, as long as he’s not your neighbour…
• “We’re almost there, I’ll set up a demo environment for you by tomorrow noon” like coping some files on a FTP host takes a day and a half
• I’ve worked on optimization…riiiiiiiiiiiiight

And in the end, a meaningful quote: I did not have sexual relations with that woman – Bill Clinton.

When I started my programming career, I was convinced that waterfall is the way to go. I felt the need to have clear specifications for the project I was working on since the very beginning. The let me see what you’ve done so far e-mails from the customers were a real pain in the ass, because since no partial releases were scheduled, I usually had to pick and choose parts of the project that seemed to work and build an adhoc release. The result was what one might call a Frankenstein of software development that had major bugs, didn’t quite work and the only thing it could do right was to annoy everybody. The client was annoyed because he was feeling that his money are not well spent and I was annoyed because I was stuck with a meddling client who doesn’t stick to the agreed plan. If the release isn’t scheduled for another three months, the he should go and bother somebody else. Maybe a government employee from the IRS. But instead of doing just that, the client was sending bug reports – fix this, change that – on the “Franky version”. So the project was slowly branching into two. We had to continue the development of the main branch, as initially agreed, but we also had to do some bug fixing and changes to the adhoc version. Fixing those bugs was taking away valuable development time and the estimated time of delivery was being pushed further and further in the distant future.

Now that he could see parts of the software, the client was changing his mind about some of the specifications and was asking for new features that weren’t originally planed. Features that were incompatible with what we’ve done so far. And…long story short: epic fail!

After spending about 2 years in the waterfall hell, I have found out about Agile development and scrum. It’s a whole different approach that divides a large scale project into smaller parts that are easier to implement, easier to test and easier to change if the customer changes his mind. In the current economical climate, even without meddling customers, a waterfall approach to software development is bound to fail. Imagine how things looked 12 months ago and how they look now. A software project must be able to adapt quickly and meet the market’s requests.

I have found this video on Adobe’s (Romania) blog that explains agile development and scrum in about 10 minutes. Enjoy!

The above video was created by Axosoft – a company that specializes in creating scrum software. If you find that video interesting, check out their site or their twitter feed @axosoft.