But it's not just simply the "correctness" of a solution that changes, that 3rd party API you're having to interface with might not return data in the same way you were expecting, the other company who were going to deliver the grid component can't do it in time anymore, half the dev team have fallen ill and are out for 3 weeks. No amount of planning up front can ever be sufficient, agile gives us devices to manage all of this that the traditional waterfall strawman lacks.
And then there's the solution itself not being suitable. Have you ever shown a solution built completely to spec in a waterfall-esque environment, only for them to say "oh, but it doesn't solve x"? or for them to start using it and suddenly realise there's some fundamental flaw in it? This is where agile comes in - you can regularly demo the software and make adjustments and reprioritisations as it comes together. It enables that conversation to be had and the change to be made when it's cheapest - early on, rather than when a huge app has been built on top of it.
Also - agile doesn't preclude stability. You can manage this with test suites (the top layer of the current project I'm working on's test suite is built against our documentation), we know if and when we've broken something because we're constantly emulating the third parties in your example using our software and asserting that it remains correct.
"Working software over comprehensive documentation"
over != instead of:
"That is, while there is value in the items on the right, we value the items on the left more."
And no, you probably wouldn't use agile to manage the project of heating the ISS. That is a very static problem space with unique requirements. Using the same framework to plan and build anything related to heating the ISS to build an HR system would be overkill. Right tool for the job, etc.
I've worked on both good and bad agile projects - all have involved managing change. The good ones didn't involve throwing a plan out & doing what you want. They merely accepted that when you start building a solution, you lift rocks and uncover requirements that you never envisaged having. In an agile environment, you can deal with that - bring those things onboard, reprioritise and rescope, giving an accurate idea of when a product is going to be delivered. In a traditional waterfall environment, these same requirements get left until the now-woefully inadequate product is built, and useless to anyone.
I believe it's unintentional - I expect it stems from JavaScript event tracking (e.preventDefault(); logEvent(e); window.location=e.target.href; Or something to that effect).
You're talking in terms of pounds, $100k is approximately £63k. I'm inclined to agree with the parent here, good luck finding a place in a decent area in Manchester for less than £100k.
We've started doing something similar. We build a lot of sites upon WordPress and upload a basic version of the twentyeleven theme (with a few base plugins) and start getting content populated ASAP, this gives the designers a good base to start from and also highlights potential content-styling before they're a problem rather than the day before go-live.
I recently wrote a little throwaway blogpost that used the embed ability of jsFiddle (http://breakfastdinnertea.co.uk/blog/keep-those-rows-line-li... - excuse the pig ugly design et al). I found it an absolute joy to work with. It also provides nice fork abilities for any ensuing discussion / counter arguments on Twitter or wherever.
Genuinely interested to hear an expansion of this. How would pretending that technical employees are hard to recruit, benefit a company politically?