September 23, 2008 at 9:45 pm
I think Agile works great in the DB, it's just different clients. Communicate often and regularly with the developers, who are your clients. Address their needs and change direction when needed.
And of course, knock them around when needed as well. A little "rugby DBA'ing" is a good thing.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 24, 2008 at 5:42 am
I can't say I every looked into Agile but the posts here intrigue me. Yet another of those great reasons for participating here.
Interestingly enough, the last time I used Cobol was at Purdue doing a semester-long software project. It was the only thing we did in the class. The instructor had plenty of real-world development experience. He demonstrated that to us, by changing the project specifications at least weekly if not more often than that. Some were put off by that, but since my team had some real experience, we appreciated it. In the end, all of us were better prepared for real jobs and the experience has paid off nicely. So I may have gotten some Agile training before the concept was formally introduced to developers in general.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
July 23, 2013 at 9:23 am
I've been developing software for about 35 years now, and have more or less been able to keep up with the times doing so.
The best software development practise, in my experience, is to plan thoroughly and execute the plan well. Understand the users' business. Understand their functional requirements. Write and review with them a detailed set of functional specifications. Elaborate the technical specs based upon the functional ones. Develop the software, carefully reviewing it with the users at each functional point. And so on.
Buzz-words like 'agile development' and 'extreme programming' come and go; our profession is no more immune to trend and fashion than any other. What works, and which stands the test of time, is what works in many other professions as well: a dedication to careful, detailed, conscientious craftsmanship.
July 23, 2013 at 9:48 am
Craig-315134 (7/23/2013)
Buzz-words like 'agile development' and 'extreme programming' come and go; our profession is no more immune to trend and fashion than any other. What works, and which stands the test of time, is what works in many other professions as well: a dedication to careful, detailed, conscientious craftsmanship.
Object Oriented, Rapid Application Development, Cascade, Waterfall, DropDown Programming, Spaghetti, Altered Gotos, Modular Development, and Appropriate Register Utilization, been there and done that. You are as right as rain! Thanks...
M.
Not all gray hairs are Dinosaurs!
July 23, 2013 at 10:00 am
Communicate often and regularly with the developers, who are your clients. Address their needs and change direction when needed. And of course, knock them around when needed as well. A little "rugby DBA'ing" is a good thing.
It's good to see a DBA viewing developers as customers. And it's also good to see a willingness by a DBA to push back at developers when truly needed.
What is true about developers is what is true about any other customer: 'The customer may not always be right, but s/he's still the customer'.
July 23, 2013 at 10:26 am
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.
July 23, 2013 at 1:03 pm
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 25, 2013 at 7:10 am
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.
July 25, 2013 at 7:04 pm
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
July 25, 2013 at 7:04 pm
duplicated comment deleted
Tom
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply