To me, this was worth the 5 minutes it took to go through. Each point was supported by good observations. As a supported of agile techniques he nearly lost me after slide 9, but made up for it.

OK, the highlights. The numbers are the slides. If you disagree with one then I suggest you look at its supporting slides before criticising in detail.

   9 Write a comprehensive specification
  16 Evaluate possible existing solutions
  21 Consider the cost of your design choices
  32 Make sure your design covers all states
  39 Design for reusability
  45 Broadband is not a silver bullet
  50 Prepare your design files read to send
  58 Build your site for cheap maintenance
  65 Build your site for low cost quality assurance
  73 Use existing APIs

His final point was

"The best way to save money is to let someone spend theirs."

There are many faults to be exposed here, but I think there are many good points to take away from it.

Thank you for submitting this.

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 summary and comments.

I'll second the thanks - I've book marked this to add to our training regimes, some great tips.

Some thoughts to add though (based on ROG's condesing). Whilst I agree with "9 Write a comprehensive specification" in slide 14 he says "Development can be planned up front". By that I assume he means planning the process by which the specification is executed: or mapping how to build the spac. That's always a point I specifically avoid doing, at least till things are underway. One of the best things (possibly the only useful thing...) I was taught at school was that a specification is about what you want to achieve NOT how you plan to do it. Purely because if you plan out in too much detail how to execute a problem then you risk locking into an inelegant solution.

2 things I particularly like are the comments about "logged in logged out" (slide 32 onwards). One of the issues I often run into (and MUST learn to avoid) is beginning a design and framework in a logged out state and never consider the logged in state till I come to add it later. I often find this is much more of a problem with code than it is with visible design. Secondly "DONT reinvent the wheel" is the #1 bit of advice ever. Literally.

:)

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.

Thanks for your comments :)

Good list.

Not sure about the comprehensive spec at page 9 though: BDUF - Big Design Up Front is often a naive approach. Requirements and constraints tend to change as you go along. Too much up front specification can be a waste if 30 percent of those features never see any use. I'm all for thinking each specific task, function and web page properly right through before coding it, though. :)

I also have trouble with "design for reusability" at page 39. Building one-off components is a waste IF you are going to build similar stuff in the future. However designing things for reuse also incurs overhead in itself that first time around. The specific project context should determine if building for reuse is cost-effective. Also, designing for reuse can be taken too far. We sometimes burn ourselves by thinking too generally - see some of the more complex J2EE frameworks out there...

Drew may correct me on this, but I dont think he is necessarily talking about the BDUF approach from a traditional software development viewpoint. ie. not documenting every detail of the system from a developer-standpoint (eg. this function must be AJAX-driven, user details will consist of x and be stored in a mysql innodb database table etc), but more as complete-as-possible account of the user stories the website / application needs to satisfy.

I've managed development teams that have very successfully implemented agile development work within a larger organisation that follows waterfall within its general IT teams. The trick is two-fold. One: remove low-level system dependencies (do you really care if i use Apache 2.2 or IIS to host the website??), and two: internally tier the requirements to allow iterative progression and evaluation.

Great list, and yes, never try to build an all purpouse library the first time you are solving a problem.