V-Base Development Blog

I’ve been a developer at YouthNet for over 6 years now, and have written much of the code behind the do-it.org.uk website, as well as our other sites, TheSite.org and youthnet.org.

One of the challenges and opportunities of V-Base 3 is greatly improving and expanding how the V-Base client communicates and interacts with the central database and website. We can send much more data in both directions to make V-Base more interactive with the website and volunteers’ profiles, to allow data sharing, and much more.

So I joined the V-Base 3 team a couple of months ago, to work on this area, and it’s been a very interesting time so far!

One of the things about working on one website for a long time is that the work tends to be small and bitty: change the look and feel of a section, add some new functionality to a profile page, that kind of thing. They normally last a couple of weeks, and will just be me working on it, or one other developer at most.

So to work on a very long term project – by the December release it’ll have been in full time development for over 2 years, and the team has grown to 9 people now. This is a first on anything like this scale for YouthNet, and the team have adopted the Agile methodology, a very modern approach to software development.

So, how does Agile compare to what I’ve done before? Is it the revolutionary improvement some say, or more a fashion statement, as others comment?

Things I like:

communication is important anywhere in development, and more so the bigger the team size and project complexity. This is important in Agile, we make a point of a short meeting every day where everyone says what they’ve done, what they are doing and any problems they’re having. I find this really useful, as I know what everyone else is doing, how their progress is going, and lets everyone else offer ideas to the others’ problems.

we’re using modern web-based project management, code building and information sharing tools:

JIRA for project management, work planning and bug tracking.

Confluence as a Wiki, to store and share all the details of our work. This is such an improvement on a local area network full of MS Word documents!

TeamCity for continuous integration, a central place the code is built and tested, great when several developers are working on the same code base.

Good and flexible working conditions. We’re all hard working, the daily standups mean you can’t get away with sitting in a corner and doing nothing but play Scrabulous for weeks. But one of the Agile tenets is that you work your set hours, and not a minute more. I’ve worked in places where the week or two before a big release, half the team is still there at 10pm every night. A happy, relaxed team is going to work better. We’re also using a VPN and Remote Desktop and IRC to be able to work from home occasionally.

Flat structure, design by meritocracy. We don’t have a complex structure of bosses dictating your every move. Whoever knows something the best can take responsibility and do it.

Iterative development. Rather than working out every detail at the start, building a huge timeline and enbarking on months of coding, the work is split out into short stretches, usually a week or two, where you decide which chunks of work need doing, and then code those. at the end of the iteration, you have a review, to see how it went, and what could be done better next time. while this means more deadlines, they’re not as deadly as when you’ve been at it for 6 months and still have half to do.

Things I don’t like:

There’s a lack of planning and design work at the start, compared to the development I’m used to. The attitude seems to be that you just go and do something, and if it’s wrong, then you refactor it based on the knowledge you gained from it, so your next effort will be closer to what’s needed. While this is a nice way to work, it’s not as effective as taking much more time at the start and getting it right first time, and a lot of time is wasted.

It’s very hard to estimate the time scale of a complex project. When you lay out everything at the start, and work out exactly what has to happen, then you can get an idea of how long it’ll take. but if you just iterate until it’s done, any estimate more than a year ahead seems a stab in the dark. Again, as a developer, it’s nice to work in this way, but it must drive management crazy!

Conclusions:

Despite its name, Agile is much stricter and has more rules than how I’ve been working here previously. You must have stand up meetings every day, you must log all your user stories and progress in JIRA, you must make sure the build compiles with every commit, etc. But this is actually a good thing, they all help, especially in a large team on a long project.

It’s not suitable everywhere, if I go back to the bitty, single-developer work after this, Agile wouldn’t be suitable – the rules and practices would be an unnecessary overhead.

Agile isn’t really anything new, and didn’t come out of nowhere. It’s a collection of sensible and practical ideas that software developers have figured out through experience over the last few decades, brought together and given a name – rebranded, if you like. And as such, it’s very easy to pick up and use. Some of the ideas and technologies I’ve used before, and some are new to me, but they really work well together when working on a big project like V-Base 3. If I work on any large projects after this, I’ll fight to use Agile.

So I’m definitely a fan, if not quite a rabid, flag-waving convert