Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

The Agile Cult Expand / Collapse
Author
Message
Posted Tuesday, July 23, 2013 10:26 AM


Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, October 23, 2013 11:18 AM
Points: 9, 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.
Post #1476708
Posted Tuesday, July 23, 2013 1:03 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 9:23 AM
Points: 1,786, Visits: 5,032
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.
Post #1476759
Posted Thursday, July 25, 2013 7:10 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 8:54 AM
Points: 128, Visits: 703
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. 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.
Post #1477471
Posted Thursday, July 25, 2013 7:04 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:11 PM
Points: 7,920, Visits: 9,646
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
Post #1477820
Posted Thursday, July 25, 2013 7:04 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:11 PM
Points: 7,920, Visits: 9,646
duplicated comment deleted

Tom
Post #1477821
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse