At the end of last week I caught the Eurostar out to Brussels to present at the very first twiist.be conference in Leuven. This was my first visit to Belgium, and my first time presenting “10 Cost Effective Web Development Techniques”, so it was a pretty fun trip all round. I’ve put the slides up on SlideShare, which didn’t translate perfectly (beware ugly ampersands), but give a flavour.
The lineup for the conference was excellent, and it was good to meet up with familiar faces like Brian, Elliot, Glenn, Aral and Chris as well as meet so many new people. The organisers did a really great job for a brand new conference, and were excellent hosts – thanks guys.
While in Belgium I took the opportunity to be a tourist for the weekend and explored Brussels (including an awesome gay pride parade!) and then kicked back to watch Eurovision on Saturday evening. Congratulations Norway. Photos of the conference and Brussels to follow, I’m sure.
Comments
Quite apart from the content, I love your slides. (the content is pretty good too)
I am not sure about the plan everything up front. My company has recently spent millions in investing changing from the old Waterfall structure to Agile development. I have encountered many many times that writing a comprehensive spec can cost more and waste time.
What a wonderful article. I gained a lot.
By “development can be planned up front” I mean on a really simple level. I think the example I gave in the presentation was that if you were implementing a user comments feature, you could reference the spec to find the other parts of the site/app that also need user comments and implement a single solution that will cover all cases.
One of the downsides to agile is that you don’t always know what’s coming further down the road, so you either have to build extremely generic solutions (usually a waste) or very specific solutions that get adapted over time (refactoring is also wasteful).
In situations where budget is tight – which is the position I was coming from – it is optimal to have solutions that are Just Generic Enough to cover needs.
I know where you’re coming from with the agile thing. Agile techniques have a lot of advantages, but they’re just one way to run a successful project – there are other ways. The reality of working for clients who need accurate estimates up front and to know exactly what they’ll get for that money demands having a spec up front. Agile works better in situations where you’re your own client (such as with a startup).
Ultimately, the important aspect is building the app/site the client wanted for a price they can afford to pay. When the budget is tight a spec works really well to push the iterations to a paper stage where they are cheap to make.
Thanks for your comments.
Re: the agile comment above. Agile has a nasty tendency to fall into chaos, and it’s ability to stay organized is predicated on a couple of factors:
1. Complete buy-in of all parties involved, to include the client.
2. The Venn Diagram representing the teams involved in projects should never overlap — ie.: Team A on Project 1 should share no team members with Team B on Project 2 — if this is ignored you end up in a situation where two unrelated projects have the ability to impact each other’s deliverables. And I’m sure Client X would be pretty pissed if their project is held up because Client Y can’t get their ducks in a row.
Now, in any agency I’ve ever worked for, there’s always about two dozen projects with tons of resource overlap. Not necessarily the best environment for agile.
As a developer, I want to hand this slideshow to every single account manager, project manager, creative director, designer, and tech director that I work with.
Brilliant.
Really really good stuff. I typed out this presentation in Word and printed it out for my reference. Let me know if you want the 2 page summery for printing purposes? Again, awesome job!!