Posted by Stan Carney on Feb 5, 2012 in Software Development Lifecycle | 0 comments

Further to my post on the Technology Behind Vogogo I’d like to talk a bit more about the software development process used. It is something that everybody has an opinion on, so take it for what it is worth. It has been an interesting last few years where I’ve been able to strip away everything that I’ve been taught about developing software and start from the beginning again working by myself.

Head Start

Make sure you know what you are building. You need to know the market and how to sell it before you can really start to understand how technology is going to solve a problem to a level at which people will want to use your product. It is possible you can come up with a killer lipstick-trading, community-driven social media site, but if people don’t gain any benefit they perceive as valuable they won’t use it no matter how hard you push it.

Once you have an understanding of the problem you are trying to solve start building your solution, by yourself if possible. I would suggest having a good working prototype or an alpha version of the software built prior to bringing any other developers on board. When you do start hiring people do it in a way where each person has a few weeks to get up to speed before the next person starts. If you hire 4 people on the same day your well thought out idea is going to get beat up, possibly to the point it isn’t recognizable anymore, as people start to transition mentally into their new roles. Unconsciously people always bring baggage from their prior work that takes a few weeks to dissipate.

 

Good People

This is the single most important part, without this there is really no point in continuing. I’ve found that most modern development methodologies like to impose arbitrary rules like peer programming, or if a feature changes after it is started you have to wait until the sprit is finished before working on the changes. These rules may net results but only after reducing exceptional developers to the same level as your worst developer. Maybe this is what you want if you are a large company who needs to fill seats and still provide a tiny bit of value to justify having an IT team. If you are startup, I doubt this is the case.

 

The Right Thing == The Simplest Thing

If your development process involves a bunch of tasks that involve people having to remember obscure steps or go out of their way to do something rather than developing software, the process will eventually fail when placed under pressure. When it is 3am and production crashes you do what needs to be done to fix the problem. If your development process is ‘correct’, fixing and deploying a problem at 3am should be no different than a regular feature being built and deployed at any other time.

 

Work Where Comfortable

It is hard enough grinding away on a bug/feature never mind doing it in the same place all the time. I’ve found I’m only productive in a given environment for about 2 weeks before I need a change of venue: a coffee shop, kitchen table, office, home office, couch, boardroom. There are times when face-to-face discussion is required and other times when it is terrible. You understand what needs to be done, but people keep interrupting you because you are there. Writing code, talking, and writing code again is a terrible thing to go through more than a few times a day. It normally results in code -> talking -> Reddit -> talking -> Slashdot -> getting a coffee -> email -> Reddit -> then maybe coding again -> home time and the feeling of a meaningless empty existence.

So how do you work collaboratively on a daily basis with your development team? I’ve found IRC to be the best solution. Unlike mailing lists or other messaging systems, IRC allows you to watch all conversations while not breaking you out of your development flow. I’ve actually known people who were actually better at communicating in IRC than in real life. In the office, if you don’t need to have a face-to-face discussion, you talk to the person right next to you via IRC. Sounds odd but it really works. People working offsite don’t miss anything and all logs can be archived and made searchable. We, mostly a talented developer named Andrew Taylor, wrote an IRC bot in Groovy called gBot that sits in the channel and posts build and ticket status. If also parses all IRC messages looking for things like ticket numbers, and when it finds one it posts a direct link to the ticket. A common occurrence is “Hey what is up with ticket #1234?” to which gBot would respond with the direct link so others in the channel don’t have to dig around for it.

There are tons of online collaborative development tools out there but I don’t really like any of them. They don’t seem to focus on long running real-time chats like IRC does or appear to be suited for graphic designers rather than development. We also use IRC as a support tool and I’d rather not have to deal with privacy issues of having an online 3rd party involved.

 

Best Tech

Don’t mandate what tools a developer can use. Sometimes the tools a developer needs cost money and sometimes they don’t. Regardless you are paying a person to be as productive as possible and if they are productive building web pages in Emacs then let them use Emacs.

 

Release Often

By often I would say as soon as a feature is done and tested it should be released. Some times it makes sense to group like features and release them together, other times it makes sense to release around site usage peaks. The sooner code is released after it’s completed the better. It will still be fresh in the developers mind if issues arise, they gain confidence and satisfaction knowing their work is now being used by customers, and most importantly they don’t fall into the mindset of thinking somebody else is responsible for it. If a developer writes bad code that makes it through testing and breaks in production, you want the developer to take it personally. You want them to fix their mistakes (or the process) and ensure it doesn’t happen again. Releasing code as soon as possible is the best way to ensure the developer still feels responsible for it.

 

It is also worth noting that this is my understanding of what works today for us. Some of it was common sense, some of it was because we were doing the wrong thing and it wasn’t working. What works today may not continue to work tomorrow, and your development process should be flexible to change.