

Cost Effective Web Development Techniques - tortilla
http://allinthehead.com/retro/340/10-cost-effective-web-development-techniques

======
RiderOfGiraffes
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.

~~~
ErrantX
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.

:)

~~~
drewmclellan
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 :)

------
thomanil
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...

~~~
daviddixon
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.

