It's amazing how a new environment, a ton of pressure and a bunch of uncertainty can make people react. I found out earlier this week how software engineers react. At a three day off site, a large group of people, both developers and 'suits', were told to leave their job titles at the door. Unfortunately for me and the team I was working with, it felt as if we'd left our software engineering principles at the door too.
Having essentially 48 hours to build a product, mostly from scratch, or at least using new products/APIs and services to plug something together seemed to suggest that we threw our best practices out of the window. Now the working environment wasn't set up exactly how we would have liked it, but we could have done something about that. Without even the basic necessity of source control, it felt as if the team were fire fighting from an early stage with USB drives being swapped around at crucial times, along with cries of "hey, can you add this method to the code?" when it could have been done easily and checked in.
I certainly felt like I was developing with one hand without using test driven development, source control, continuous integration et al. If three days being thrown into the deep end has taught me anything, its to be prepared.
I once heard the phrase, "a bad tradesman blames his tools", but conversely, does that mean that a tradesman is only as good as the tools he uses? Perhaps I've grown so used to the tools that I use that I've come to depend on them, and while that encourages best behaviour, does that make me inflexible?
6 comments:
I can see the case for not doing TDD (or only test-driving the important bits) for a spike, but it definitely looked to me like you could have used a subversion repository! Would have taken a few minutes to set up, and paid them back in no time.
I guess the same applies to CI. Arguably you could do without it (especally with no tests!), but I noticed that the Railsfest at Agile2007 suffered from having no CI too (although to be fair most of the pain was caused by code checked in by Alkesh and me).
At an offsite I was at a while back, I think we did set up CI and other Agile tools, but only to impress the judges rather than to help us! :-)
You can even do TDD, but of course the ridiculous pressure you're under discourages that.
The whole process is crap IMO, it'd be better to actually spend the time 1. getting a customer that will be available for the duration and 2. agreeing the high level stories.
Will the winning team go on to produce the actual product? That was the original plan for Off-sites.
I agree entirely - At the very least, source control would have saved much of the pain and eventual friction involved in building something that quick. I'm a pragmatist and notionally like the idea of hothousing. In practice however, it often results in a few decent ideas and some sh**ty software at the end.
Wow, 3 whole comments =)
@kerry, I completely agree that TDD probably isn't worth doing for a spike *if* you have intentions to throw the code away and only take the learning with you.
As for source control, spot on again. Sometimes it just takes someone to just do it, and for some reason that just didn't happen.
@adrian, the intention was to take at least one product forward, maybe more if they're deemed worthy. However, the products most likely to be picked already had been live in small trials, so tell me what the intention is there?
@nigel, I can see some benefits in these off sites, but I would like to see them run differently. Like I was saying the other day, I'd really like up to a week to be put aside and everyone to be brought in to spilt up as they saw fit and just build some cool stuff with the tools and services we have and that others offer. However, I'd want it to be a more relaxed atmosphere to encourage innovation and experimentation. Do you think they'd be more benefit in targetting a few issues and getting people to just go wild, and have business people on the side to support the support the process, not to endanger it?
It would seem the such things as source control systems aren't a basic whose presence are to be taken for granted as I'd assume. I now know two people working at different companies, both producing software as a product, where they don't use source control systems.
I'm starting to appreciate why some people seem so baffled by some of the technical Agile practices when they don't even follow very basic software engineering practices.
@paul, I couldn't even imagine not using source control at the very least, let alone the rest of the toolbox.
Post a Comment