August 28, 2009 at 7:01 am
I'm sure the article will kick up more mud. Interestly enough, most of the Agile projects at my company have failed. The constant redesigns and refactoring was leading to little to no completed code. They were shut down. Some of them have restarted as more traditional development, a few moved over to Microsoft Dynamics.
One of them has gone down the track of FDD, feature driven development. They're using nHibernate to push an object oriented data persistance layer down to the relational database. After almost a year of development, the DBA team, who has been largely shut out of their process, still hasn't seen a bit of structure come out of the dev team, so we don't know how it's going. The only indication I have is that they contacted us recently to ask if we could go to Oracle because they thought it might offer a better transaction isolation methodology. We couldn't get out of them why they thought this or what problems they were having that they needed this. They've gone back into their hole. It'll be interesting to see what finally comes out.
At this point, only based on personal experience, not extensive industry knowledge, Agile is a nitch player and isn't likely to radically alter the landscape further than it already has.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 18, 2009 at 5:52 am
I 100% agree, and would add another factor: it's difficult to involve clients in that a close way. Clients have their own concerns, responsabilities, and need to dedicate the most of their time to the bussines, that is, relations, decisions, management, etc.
September 18, 2009 at 8:38 am
Nice article. I'm involved in setting up an agile users group my area. The interest is pretty big. I'm just wondering if this will be the latest "flavor of the day" and five years from now it will be just an ancient memory. But, as you pointed out, it's nothing new.
I've been doing iterative development for years now. It's always brought better software and the customer is always happier.
On the database side of things, though. You really need to have DBA's who are willing to be less rigid in their work styles. I've known some that once a database is set up, that's it, no changes. Agile is in complete opposition to that mindset.
September 18, 2009 at 9:17 am
Hey folks. I had fun scanning the original article and the old posts. I keep my eye on the topic of Agile so I can learn more - and learn how to be more agile (get further into the safety zone, make projects succeed, enjoy the process) in database development.
Up until recently, I wasn't aware of the origins of the Agile movement - and hence didn't understand it very well. I get the feeling that many other people don't know either - even people who say they practice it. Here's some points that have helped me.
In short, a group of really good developers held a small conference in Park City, Utah - at a ski resort in the year 2001 or so - and talked about best practices, about how to keep projects from failing and about making the profession of software development sustainable - i.e. improve the working-life of developers. (That last part gets omitted a lot these days. I think developers get treated like a CPU - and the idea is for Agile to improve their efficiency and throughput, i.e. one sprint after another after another. What happens when they overheat?)
If you haven't read the Agile Manifesto, I suggest you do at your next convenience. It's brief - but a lot of thought has gone into its brevity - and it should provoke much thought because it notes the key trade-offs of the approach - valuing one thing over another thing. http://agilemanifesto.org/. Don't assume that you understand Agile until you've pondered the manifesto (It takes more than that of course). You know how things go - the further from the source, the signal changes.
I hear people say "Agile has it's pros and cons" and I think - of course it does. But it does better than that. The founders do us the favor of mapping out the pros and cons and trade-offs up-front - so we'll know what we're gaining and giving up.
Alistair Cockburn, one of the founders of the movement has said that Agile wasn't new - it was a set of best practices that the founders materialized. So it's no slight on Agile when people say things like "I was doing Agile before it was even coined" or "It's nothing new really."
I've been listening to Cockburn's new talk and I recommend you do as well if Agile is a thing relevant to you: http://www.infoq.com/presentations/cockburn-bury-not-praise-agile.
Agility can be achieved through a variety of various "practices" like running tests, setting up a walking skeleton, and so forth. But that's not all. It's also a set of "properties" like your team communicating effectively, like there being an environment of personal safety (It's safe to say what you mean, or to reveal that your skill level is too low for the requirement). The properties in the end are more important for project success, according to the studies. All this is well-put in Cockburn's book Crystal Clear: A Human-Powered Methodology for Small Teams.
As Cockburn says, the "iceburg" of Agile has already melted into the ocean and has become a part of it. Increasingly, It's what we do. However, we still need to be alert because each project is unique.
Bill Nicolich: www.SQLFave.com.
Daily tweet of what's new and interesting: AppendNow
September 18, 2009 at 12:26 pm
For me the most important thing about "agile" is that it emphasise communication and that the best communication is face to face.
Short itterations mean that developers and business people get used to talking to each other. It isn't an activity that is for a select few at the start of the project it is continual for all throughout the project.
For "agile" to suceed everyone affected by it has to buy into it. If you end up with open warfare between DBAs and non-DBA development staff then it is all going to end in tears for at least one of those groups and probably their company as well. Ideally non-production DBAs get absorbed into the general development pool.
Scott Ambler's vision was that there would be developers with specialisms rather than isolated specialists. If you have a burning desire to be "just a DBA" then you could find your role shrinking to a production only role or just plain obsolete. This would be to both your companies and your detriment.
September 18, 2009 at 12:51 pm
I like that you mention, this methodology is nothing new. But Agile, extrem programming, scrum... are all just buzz words. To me your article really doesn't say much people don't already know, but at least you didn't drag it out to a 200 page book.
Check out PMSProgramming.com for a different perspective and if you really want to make a difference in project managment.
September 18, 2009 at 1:35 pm
Well written, laced with both sage advice and great explanations. I particularly liked your thoughts regarding short, direct lines of communication between stake holders and developers. All team members should be required to communicate effectively (regardless of how technically inclined they might be) and a customer, client, or stakeholder should be considered a member of the team. As such they should very much share responsibility for a project's success or lack thereof. At least I feel that way about internal clients. Nonetheless, thanks for article.
September 18, 2009 at 1:50 pm
Amen! My personal experience agrees with your points 100%. Nice job, I intend to share this with all the Developer types in our shop.
September 18, 2009 at 3:27 pm
Nice article on the impact Agile can have on DBA's, David.
Full disclosure: Agile Scrum Master here!
Agile can work well in a lot of situations, but you do need to get buy-in from the people involved. I'm 'mastering' several Agile projects (since January 2009), and we're seeing a lot of benefits from the process.
One thing that hasn't been mentioned yet, either in the article or the responses, is that Agile was in part designed to expose obstacles posed by the corporate culture. This allows you to remove the obstacles - assuming you have some support from upper management. If you don't have a fairly powerful Agile Champion (buzzword alert!) in the upper echelons, it will be difficult to succeed with Agile methodologies.
I'm fortunate that our CTO is both our Agile Champion, and a VERY effective communicator at the upper levels. I have a regional VP on one of my Agile projects - he's the Product Owner (for those steeped in the Agile buzzwords, again). Great to work with, can make fast decisions about what he needs from us. We're on track to complete a project in two months - very tight time schedule. We're using 2-week long Sprints.
Another of my projects has an external client in the Scrum - another Product Owner, very quick to make decisions or get us information that we need. We couldn't succeed without her, because she know what she wants - not us! We need her input, and her review of use cases, web screens, data gathering, and so on. She discusses code issues and database structure questions directly with the DBAs and Developers, and I occasionally do a little translating from geek-speak to client-speak. The team is highly productive, communicates well, and the client is VERY happy with the most recent demo of the software.
So YES, Agile can work. It takes some work, some practice, some commitment, and the ability to be flexible. But I LOVE what it's doing for my projects - if they don't come in "on time" (meaning we don't meet that unrealistic deadline that someone pulled out of a hat), EVERYONE on the project know why, and understands how it occurred. I'm a convert, ever since the first time one of my internal clients said "Oh, it's US that are the obstacle! We'll have to get better at this." Music to my ears... :w00t:
Steph Brown
September 18, 2009 at 3:41 pm
Have to say, the title of this article is hillarious and made me smile for a straight minute.
September 18, 2009 at 3:47 pm
Sorry for top posting, but this was long. But wow, you make it sound like non if this could have been done unless someone 'invented' Agile. Shorten iterations and take customer input, what a concept. Another example of PMS Programming
Stephanie J Brown (9/18/2009)
Nice article on the impact Agile can have on DBA's, David.Full disclosure: Agile Scrum Master here!
Agile can work well in a lot of situations, but you do need to get buy-in from the people involved. I'm 'mastering' several Agile projects (since January 2009), and we're seeing a lot of benefits from the process.
One thing that hasn't been mentioned yet, either in the article or the responses, is that Agile was in part designed to expose obstacles posed by the corporate culture. This allows you to remove the obstacles - assuming you have some support from upper management. If you don't have a fairly powerful Agile Champion (buzzword alert!) in the upper echelons, it will be difficult to succeed with Agile methodologies.
I'm fortunate that our CTO is both our Agile Champion, and a VERY effective communicator at the upper levels. I have a regional VP on one of my Agile projects - he's the Product Owner (for those steeped in the Agile buzzwords, again). Great to work with, can make fast decisions about what he needs from us. We're on track to complete a project in two months - very tight time schedule. We're using 2-week long Sprints.
Another of my projects has an external client in the Scrum - another Product Owner, very quick to make decisions or get us information that we need. We couldn't succeed without her, because she know what she wants - not us! We need her input, and her review of use cases, web screens, data gathering, and so on. She discusses code issues and database structure questions directly with the DBAs and Developers, and I occasionally do a little translating from geek-speak to client-speak. The team is highly productive, communicates well, and the client is VERY happy with the most recent demo of the software.
So YES, Agile can work. It takes some work, some practice, some commitment, and the ability to be flexible. But I LOVE what it's doing for my projects - if they don't come in "on time" (meaning we don't meet that unrealistic deadline that someone pulled out of a hat), EVERYONE on the project know why, and understands how it occurred. I'm a convert, ever since the first time one of my internal clients said "Oh, it's US that are the obstacle! We'll have to get better at this." Music to my ears... :w00t:
September 18, 2009 at 7:49 pm
Having had a quick read over this, I'd like to mention two great (and free!) ORMs for .NET. A bit OT perhaps, but there is a lot of discussion of the dev process happening.
SubSonic (www.subsonicproject.com.au)
builds all your CRUD for you, and wrappers for all DB objects. From a DBA perspective, it is refreshingly non-presciptive in its approach (ie. doesn't railroad you into a particular philosophy of doing things) - it just helps developers do what they were already doing, more quickly.
Subsonic is for 'lightweight' projects (it is aimed at website devs, but can be used equally for forms application development).
For the enterprise-strength apps out there, CSLA .NET (www.lhotka.net/cslanet/) offers out-of the box features which trump any ORM I've ever seen - security, compression, object remoteability over different layers. You have to buy his book to get the full 'product manual', but reading his discussion of software layering (ie. tiers) alone (the first 40 pages) is worth the price of the book.
Again, it automatically generates an entire layer for you. The only thing which I don't understand is why it's not way more popular.
They are both .NET I'm afraid, but remember that .NET is essentially rebadged Java 🙂
The recent features of .NET such as generics and partial classes are leveraged to great effect.
(My excuse for mentioning this is that I find these tools invaluable in agile development because they take so much of the work out of coding and re-coding the Data/Business Logic layers)
Ben McIntyre
-------------------------------------------------------------------------------------
"We must never forget that if the war in Vietnam is lost... the right of
free speech will be extinguished throughout the world."
-- Richard Milhouse Nixon, 10/27/65
September 19, 2009 at 4:15 am
I've just been reading "The Mythical Man Month" by Fred Brooks. Some people think his book is brilliant other people deride it with comments such as "it taught me nothing new".
Those who deride it should look at the publish date. It was written in 1975 based on 25 years in the computer industry. I have the copy with the 1995 adendum. My point being that the book is the IT equivalent of Genesis.
You can clearly see the germination of ideas that are now part of agile development. For example Harlan Mills advocated an itterative approach back in the 1970's and he wasn't the first. From what I can gather the idea of iterative development dates back to the 1950s.
September 20, 2009 at 2:22 pm
An example I have worked on that used the iterative approach did so purely for reasons of cash flow. The project was a £500K project in total but the company I was working for was small and couldn't survive the wait for an end-of-project payment. The project was broken down into a series of phased deliverables with payment on delivery.
Nothing I have read on agile development mentions cash flow and I think this is a major omission. It offers a win-win situation
* The development company gets paid per deliverable.
* The customer gets the use of software commissioned to help their business.
Take a look at work done by Mary and Tom Poppendieck at http://www.poppendieck.com/ and in particular their book "Lean Software Development: An Agile Toolkit" that has a chapter on contracts. And I seem to remember hearing mention of a book completely dedicated to Agile contracts that is soon to be released if it hasn't already been, but sorry, I can't remember the name.
September 21, 2009 at 6:51 pm
Regarding Visio 2007:
Question: Does Visio 2007 support forward engineering of DDL?
Answer : No, Visio 2007 does not support forward engineering of DDL. Only, Visio for Enterprise Architects (VEA) supports forward engineering of DDL.
Question: Is VEA installed as part of VSTS 2008?
Answer: No, VEA is not installed as part of VSTS 2008. VEA 2005 is a supported product.
Question: Does Visio 2007 Pro support Database modeling?
Answer: Yes, Visio 2007 Pro does support database modeling. Please go to http://office.microsoft.com/en-us/visio/FX101759431033.aspx for a feature comparison.
Viewing 15 posts - 31 through 45 (of 47 total)
You must be logged in to reply to this topic. Login to reply