SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

The Agile Cult

The Agile Cult

anelson 66875
anelson 66875
SSC Rookie
SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)

Group: General Forum Members
Points: 37 Visits: 73
Booch Brady and Rumbaugh originated CMM? Umm, no.

CMM work started at Carnegie Mellon in the mid 80's, as a way for DOD to try and assess how their software contractors were doing. The original author was Watts Humpheys, based on earlier more general engineering work by somebody I don't recall. The CM authors who released the eventual CMM book were Paulk, Weber, Curtis and Chrissis (it's sitting on my shelf laughing at me now).

What's the point of trying to attach CMM to Booch, et al.? Just being cynical?

People who think deeply about possible ways to improve your life as a developer, are actually our friends. Doesn't do us much good to blow raspberries at 'em.
Eric M Russell
Eric M Russell
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: General Forum Members
Points: 62977 Visits: 12808
You can call your process whatever you want, but what really matters are requirements, ticketing of tasks and bugs, source control, peer review of code, seperate dev / qa, production environments, and weekly team status meetings.

"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1862 Visits: 1081
I like Agile but there are problems with it and those who ignore them will suffer for them. Here's a few

There's no fixed deliverable. From a developer's perspective that's Nirvana but now imagine you're the salesman who's got to sell a client on: "We can't tell you exactly what we're going to deliver for you and we can't tell you exactly when we're going to deliver it but whatever it is will make your life better. That'll be ten grand a month please." Agile software houses have to work as partners with their clients but the client doesn't really want a partner, they want functionality. Convincing them that the partnership will deliver the functionality can be easier said than done.

Agile has no critical path. It can't do because it has no defined end state. That means it's impossible to know when an agile development is slipping or how badly. If the whole project is geared toward "adding value" that's not a problem, but sometimes that's not enough. Imagine a politician being grilled on radio 4 on the progress of a wizzy new traffic control system. Can he really get away with saying: "We've delivered some improvement. It's ongoing. We think we're getting value for money." John Snow would eat him for breakfast. In some scenarios (particularly but not limited to government) a defined deliverable with defined milestones is a requirement.

Agile requires the client (or a representative of their interests) to invest considerable amounts of time in the project on an ongoing basis, both to test the delivered functionality and to feed in new requirements. Often they simply do not want to do this. I think most of us would agree that they should be spending this time regardless of the methodology being pursued but the reality of getting them to do so differs wildly from that. The consequences of that are that the team will deliver what they think the client wants instead of what they do want. Of course, with a waterfall you'd see the same effect... but at least you'd have a contract to cover your derrier.

Agile requires that the implementation be malleable. It's interesting to see folks saying that databases don't lend themselves to agile development and I suspect I know why. Databases are brittle. Get 'em wrong and your whole edifice crumbles. Any code in stored procedures will, of course, be procedural rather than OO and they tend not deconstruct to small elements easily. That means techniques like TDD are all but impossible to use against them. In fact, we came with a whole adjunct to TDD (dependancy injection) pretty much to avoid the unpleasant truth that we don't really know how to test the data that underlies our model very well. The data is the ultimte dependency... so we fudge it. Honestly, as a dev I pity the poor DBA, your life looks like hell to me. It's probably why you always seem so grumpy:-P. It's not just the DB that suffers from this either. If you've inherited some monolithic system written in the early 80's you'd be a fool to tell yourself that applying agile development to it's ongoing maintenance will be easy.

Finally, Agile assumes that functionality can be delivered in bite-sized pieces. Often it can't. Often the functionality is useful ownly in it's totality so what do we do? We run either run a long sprint or we run a series of short ones in which the deliverables are untestable... which is the same as a running a long one anyway. And what does a long sprint look like? A waterfall.

I really like agile but it isn't perfect. It's no more a silver bullet than OO was, or structural decomposition. There's a plethora of techniques that can help us deliver better software and the keyword there was "help". It won't do it for us and it won't always be suitable.
Tom Thomson
Tom Thomson
SSC Guru
SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)

Group: General Forum Members
Points: 51080 Visits: 13160
I think that's a great editorial, because it asks real questions.

But... CMM is one of my pet hates. It is a terrible idea. It tells you nothing. It builds a useless paper-chase.

Agile is another story altogether. It's just a new term applied to a bunch of things that existed and were done for decades before the term "agile" was invented. Maybe it's the wheel, reinvented as a not convex polygon (or maybe it's convex - whatever, it certainly has some nasty sharp corners)- I don't know, because I can make very little sense of it.

Decades ago I worked in a world where development, testing , quality assurance, and release were all incremental; there was no magical goal; the requirements might change; was that "agile"? We built what is probably the longest surviving mainframe operating system in the world (ICL's VME/B OS was first shipped to customers in the early 70s, and is still being shipped today, by Fujitsu; call it a contemporary of Unix if you believe that Unix was a serious mainframe OS before Ucb got hold of it and gave us BSD Unix) using those techniques. None of us had ever heard of "agile", since we were doing this long before the term had been invented to hijack as subset of well understood good software development practise; and of course the guys at Bell labs were using similar techniques, and they had never heard of "agile" either.

The difference between what we (and others) were doing and what's now called "agile" was fourfold. First, we didn't have a bunch of brain-dead hype merchants explaining to the world that what we were doing eliminated several critical necessities of the development process: the necessity to recognise that the customer might have a requirement; the necessity to do some planning; and and the necessity to commit to something. Of course no-one in the "agile" camp (as opposed to those in the sensationalist journalism camp) fails to understand those first two essentials, but some have discarded the third. Second, we didn't claim that we could vastly reduce the cost of software development by throwing away the idea that our commitment could be to something real, measurable, and quantifiable rather that to something rather vague. Third, we didn't claim that the only alternative to our approach was the waterfall method (which at least as early as 1970, was known, by everyone competent in software development, to be a recipe for catastrophe on anything but a very small project), so we were not claiming that every-one else in the world was dead from the neck up. And fourth (unlike the "agile" game , or the "OO" revolution) we were actually doing (at the same time as many others - that's how research works) something new and different, not just sticking a new label on a decades old technique.


Tom Thomson
Tom Thomson
SSC Guru
SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)SSC Guru (51K reputation)

Group: General Forum Members
Points: 51080 Visits: 13160
duplicated comment deleted




You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum