InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comFri, 24 May 2013 19:11:14 GMT20http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxMy first exposure to agile lead me to think of it as the bodge it and wing it methodology. It fundamentally isn't. It isn't even a methodology, it is a set of principles.The means by which requirements are gathered and designs produced is much more informal but the shortness of communication lines means that it is much more relevant. I've just had the first team meeting on a project and straight away a discussion begins on the way in which the business users want to capture contact details on a form. This discussion is mainly beween the poor sods who are actually going to use the system and the poor sods who are actually going to develop it. The traditional approach would be for an analyst to talk to a line manager and produce a document that (assuming it was read thoroughly) could be mis-understood by all.Early on in the project a great deal of time is spent at whiteboards drawing out how the system will work from the user perspective and how the fundamental architecture will look. The resulting drawings are photographed and the resulting jpegs captured for further reference. In fact the first itteration is usually ALL design and feasibility studies.Subsequent iterations also have a lot of design discussions but will actually produce test cases and code.If you've not done it before it is very alien. Expect it to be 3-6 months before you start to feel comfortable with it. I think it will probably be 12 months before you are as productive with agile as you were with previous approaches. If you do it correctly you should see quality improve. I stress again, it takes quite a while for the processes that come under the banner of agile development bed in.Tue, 22 Sep 2009 13:24:31 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote][b]Stephanie J Brown (9/18/2009)[/b][hr]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:[/quote]This reads to me you are enthusiastic to have a customer that does what a customer is supposed to do for a project to succeed. But how much less of this benefit would a non agile method get is the valid question to ask. Given the same customer and experienced designers/modelers, I think you get the same synergy and for developers have even clarity before they start coding.Now the question becomes what benefits beyond the above did the agile method bring that cannot also be attributed to having the correct people do what they are supposed to do anyway. In IT I seen the same people jump from one ** insert new thing ** to the next, always claiming the newer is better and the old doesn't work. While this implies they are always wrong, they still claim the opposite every time and never seem to have learned anything from the past....people are wise to be follow such trends with caution.There certainly have come new things to the field that advanced developing such as XML and the internet that allowed more flexible networking. But when it comes to organizing and developing code none of the for example DLL/OO/component/generator trends ever turned out to be the holy grail advocates made it to be. Each and every time the next incarnation declared the previous obsolete and makes all the same mistakes all over again. A lot of energy was spend that could have just as well gone into skilling up and develop ways to improve human/customer interaction.If the core of the problems derive from non technical issues, namely how to organize and communicate then do not expect a technical solution to fix it. I welcome any change that improves customer involvement and awareness, but can do without the circus acts usually surrounding these things. In fact it puts me off, which means the most fanatic supporters are missing the point of what they do in the first place.This last paragraph is not addressed to you by the way, just something in general.Tue, 22 Sep 2009 05:53:30 GMTpeter-757102http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI have my concerns about agile development and I suspect that it is like all other methodologies prone to being applied wrong due to it being used for its buzz value. I am inclined to qualify it as much as a marketing instrument as a development methodology at this point. At the core the good points are in my view the bigger role of the customer has and the iterative development that supports this involvement. But comparisons of methodologies are usually done in a Duracell kind of way. A mediocre battery brand that compares it’s batteries to the most basic of all batteries and then advertises theirs lasts 7 times longer. What is most important is how does it stack up against other forms of development and which one is more suited to your customer and line of work?I got a bit of experience with DSDM myself which looks far more traditional in the sense of roles and the analysis upfront. Its strong points are essentially iterative prototyping and project manageability in both time and costs. For this features are essentially prioritized and not everything on the list will necessarily make it in release. This means the customer must be willing to accept this and get involved in the design and prioritization process to get the most useful result. No longer can a customer deliver a list of things it wants and call it specs and then set a deadline and negotiate a price. The list of customers willing to go the length on this is not big…most do some unguided in-house brainstorming and only then a 3rd party is sought to build it.For us IT professionals to have discussions on how to develop where the design and prioritization is far more important for a project to succeed is strange. This sort of discussion should be on management forums and so I can fully agree with an earlier poster that you need high level management (and customer) support for agile development to deliver. Without it you are likely to just end up with hard to maintain underperforming prototype code delivered too late and over budget.Tue, 22 Sep 2009 04:36:56 GMTpeter-757102http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxRegarding 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.Mon, 21 Sep 2009 18:51:38 GMTcppprogrammerhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote]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.[/quote]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.Sun, 20 Sep 2009 14:22:03 GMTTom Bakermanhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI'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.Sat, 19 Sep 2009 04:15:28 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxHaving 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 [i]way [/i]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/65Fri, 18 Sep 2009 19:49:46 GMTben.mcintyrehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxSorry 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[url=http://PMSProgramming.com]PMS Programming[/url][quote][b]Stephanie J Brown (9/18/2009)[/b][hr]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:[/quote]Fri, 18 Sep 2009 15:47:19 GMTdan parkerhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxHave to say, the title of this article is hillarious and made me smile for a straight minute.Fri, 18 Sep 2009 15:41:01 GMTCaleb-142520http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxNice 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:Fri, 18 Sep 2009 15:27:57 GMTStephanie J Brownhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxAmen! My personal experience agrees with your points 100%. Nice job, I intend to share this with all the Developer types in our shop.Fri, 18 Sep 2009 13:50:20 GMTdeewileyhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxWell 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.Fri, 18 Sep 2009 13:35:43 GMTjim7429http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI 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 [url=http://PMSProgramming.com]PMSProgramming.com[/url] for a different perspective and if you really want to make a difference in project managment.Fri, 18 Sep 2009 12:51:15 GMTdan parkerhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxFor 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.Fri, 18 Sep 2009 12:26:21 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxHey 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 [url=http://www.amazon.com/gp/product/0201699478?ie=UTF8&tag=sqlfave-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201699478]Crystal Clear: A Human-Powered Methodology for Small Teams[/url].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.Fri, 18 Sep 2009 09:17:31 GMTBill Nicolichhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxNice 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.Fri, 18 Sep 2009 08:38:09 GMTOCTomhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI 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.Fri, 18 Sep 2009 05:52:53 GMTkeyser soze-308506http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI'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.Fri, 28 Aug 2009 07:01:38 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI've seen that this article is going to be published again in the 3rd week in September 2009. A great deal has changed in the 18 months since I wrote the original article and while there is much in the original I still stand by there is also a considerable amount that needs revisiting. I intend to write an update now I have a better (but by no means exhaustive) understanding of the subject.I remain enthusiastic about agile development but in large IT organisations it will radically effect the role of the DBA. My experience is that if you want to be a production DBA keeping the wheels turning then there is still a role for you. If you lean more on the development side then you are going to have to morph into a more general developer with a highly developed database speciality.I have had various reactions from developers. Most are enthusiastic about getting to do DB work and to learn more about it. My experience is that they tend to reciprocate and help you gain a broader set of development skills.The agile evangelists tend to be , well, less welcoming. A sizeable number seem to regard their work as a divine calling and that DBAs are obsolete dinosaurs who should be grateful to be put out of their misery.There isn't really an awful lot of information out there to help a DBA who wishes to practise agile development. I've found that questions that I feel are legitimate have not been answered and have even been met with derision and scorn. Some of those questions are fundamental to the data professional mindset so there needs to be a constructive discussion on the issues.How do you make a multi-terrabyte datasource agile?If you use an ORM tool that requires direct table access how exactly do you secure your DB and DB server? If I am responsible for the sanctity and security of the data I want to hear a damn site more than "well so-and-so uses it". I am surprised by the number of UK developers who have never heard of the Maginot line http://www.bunkertours.co.uk/the_maginot_line.htm which used to be part of the history syllabus for all 13-14 year olds. It was basically a perimeter security measure that was ideal for defending against a specific attack. Bit of a chocolate fireguard if the attacker used a different method though!Fri, 28 Aug 2009 06:34:55 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxglad to hear you are a fan of documentation tools. here's a shameless plug for one I wrote. :) It supports 11 different DBMS in addition to SQL Server. It's called SqlSpec, see the link in my sig for details.Sat, 08 Mar 2008 09:47:55 GMTjezeminehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI worked on a project using VS for database professionals and was initially very impressed. I say inititially because I found that deploying the project to an existing database was an absolute car crash.I needed to be able to write scripts that performed tasks dependent on the server on which they were being run but the parser instantly threw an error if I tried anything but the simplest thing.If replication was involved using a SQL2000 box then my world became one of pain and stress.The things I wanted to do seemed to require me to use the pre and post scripts in the deployment but if any errors occurred it wasn't set up to do a roll back.The tool was parachuted onto my desk with "we are now all going to use this" as the only instruction. I know VS can do one hell of a lot more than I know to do with it but without some sort of "How to" guide I felt I was fighting the tool rather than using it.The last thing you want is for a tool to screw up a 4TB LIVE database where the maximum down-time allowed at any one time is 5 minutes!Let us suppose that I was altering the structure of a table and associated data changes. My manual script approach would be to do this in isolation as a unit of work, then move on to the next table that needed altering etc.I wouldn't try and drop all replication, constraints etc up front, then alter all tables, then do data work as this would be too high a risk, but this is what VS seemed to want to do.I haven't found any good articles on VS for DB professionals yet. As this version of VS is extremely expensive I don't expect any good articles anytime soon.Sun, 17 Feb 2008 05:08:34 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote]Other notes:- Unit test coverage (and better yet Test driven development) of the data provider is CRITICAL. This is hard when you introduce a state machine like a database - lots of setup and tear down, but it is worth every hour invested.- You have less code to test compared to all the CRUD code that is generated in other architectures, but it is harder code to test and more critical. (A bug could affect multiple tables.)- Isolate your unit tests from the production tables and production classes that will interact with the provider. You don't want to mix developer or DBA bugs in your unit tests of the provider. Again, more work but greater peace of mind.- Create integration tests that help you flush out storage-related errors in the in the production classes and possible mistakes in the database schema.- If there is not an explicit way to determine what data in the domain classes needs to be stored, write tests to point out areas you might have missed.- Unit testing in Visual Studio (2005 Team Edition) is difficult and does not lend itself to test driven development. It's a shame the Microsoft tools haven't advanced further, but the testing is still worth the effort[/quote]You might want to take a look at the DB side of VSTSWhile I mostly agree on the app code side - the DataDude (VSTS for the DB professional) projects allow for pretty darn seamless setup and tear-down all at the click of a button. drop everything in test database, recreate everything in test DB, and run tests to doublecheck everything, in one click.The testing stuff is not 100% of the way there for the database side, in that it's harder than it needs to be I think (in particular - some of the "standard tests" I would have hoped for are missing so you need to build them). but still - once you start setting up various tests and test "templates" (reusable tests that can help search for a specific condition for you), it's not so bad (in other words - learning curve is a B***CH, but you can often can get away with reusing and building on previous tests).A little mouse once told me that one of the Andy's (Paging Mr Leonard) that post on here is writing a book on the subject (or - contributing to a book on the subject). Perhaps we can get him interested in an article on the subject matter. I unfortunately am but an amateur in the field so far.Fri, 15 Feb 2008 11:41:03 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxSteve,Your previous feedback is something useful that I can do something with. The situation I am in is that I am trying to move towards agile development but I'm coming from a traditional background.It is far easier when you have someone to guide you through the processes and techniques. If you don't have any reference other than variable quality books and opinion then it is trial and (one hell of a lot of) error.Hope you get around to writing that article soonFri, 15 Feb 2008 11:26:50 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxThanks for the details Steve. I will not have time to go through your linked material until next week, but I will read it and then re-read your bullet points. Being a traditional waterfall guy and getting thrown into a development group that is agile is definately a culture shock for me. I'm willing to learn and change my thinking, but I will understandably go into it with caution and questions. Please do submit an article when your project finishes. I'm sure it will spawn more good discussion.Fri, 15 Feb 2008 09:26:42 GMTJohn Rowanhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxGrant,Interesting approach also. I fully realize that some applications will be all about data and its reuse.I am only against the preconception that everything must first be thought about from the paradigm of a relational database. As Matt stated, often it is a person with a hammer thinking everything is a nail.RDBMS's are still the "King" of many software developments and I have a great appreciation for them and what they can do. Other options are evolving - often to keep pace with changes in development (Object oriented, service oriented, distributed, etc.)I also tried other types of providers for our project:- DB4O - an object database for the .NET framework.- nHibernate - a object-relational mapper package.They all worked. They all had pros and cons in our environment. We ended up choosing SQL Server and a custom ORM for the production provider for some good reasons and some "not so good" reasons. It was still worth exploring the options. Maybe on a future project we will handle data in a way that reduces the need to map between object and relational.It's about keeping an open mind.Fri, 15 Feb 2008 08:07:58 GMTSteve Schmechelhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxOk John,Maybe I spent to much time bashing the article and not enough being constructive. Let me give you some insights and resources that have helped in my journey thus far.Scott Ambler has a great essay on "The Design of a Robust Persistence Framework for Relational Databases". It is available online at [url=http://www.ambysoft.com/essays/persistenceLayer.html]http://www.ambysoft.com/essays/persistenceLayer.html[/url]I combined this concept with another established idea of a "pluggable data provider" that I first experienced working with DotNetNuke.You will find this idea also in NET 2.0's Data Provider Factory Classes (originally in Application Data Blocks). Mostly, these deal with plugging in different relational databases. (DNN uses it for other parts of the WebApp also.)Links:DotNetNuke Whitepaper (unfortunately not on the DNN site anymore): [url=http://www.websecurestores.com/LinkClick.aspx?link=DNN+Documentation%2FDotNetNuke+Data+Access.doc&tabid=85&mid=588]http://www.websecurestores.com/LinkClick.aspx?link=DNN+Documentation%2FDotNetNuke+Data+Access.doc&tabid=85&mid=588[/url]More recent related post: [url=http://love-dotnetnuke.blogspot.com/2007/10/provider-model.html]http://love-dotnetnuke.blogspot.com/2007/10/provider-model.html[/url]While our application is not a web application, and I didn't limit myself to just relational databases, I found that these methodsadded to my ability as a database developer to operate in an increasingly "agile" development environment.How you ask? By making the data provider more "robust", the developers were shielded from the relational database world. This had two benefits:1) They could concentrate on object oriented design and programming without needing to understand how things were persisted in the database.2) By removing any traces of the database, it was less likely to influence their design. (As I stated before, that this was an existing problem.)By making the data provider pluggable, I could swap in a simple object serialization provider during the early stages of development, to avoid a direct dependence on the database.This allowed developers to:1) Change their object model as frequently as desired and even refactor entire branches without dependencies on the data layer.2) Exercise the running application with data storage enabled using the same interface that would be used in the production environment.They did months of initial development on a multi-tier application that will use a SQL Server database, without ever touching a database!During this time, I have been preparing the "SQL Data Provider" to accomodate the their "Domain Classes" (see Ambler article). Another DBA has been working with me to prepare the schema of the production database.By the way, we are outnumbered 10 to 1 by code developers, so you can see why having them wait on us to keep their databases in a usable state amidst their constant code changes would be a DB developers nightmare and affect their ability to be agile.When a section of the application model begins to solidify and the change rate slows, that's when we begin configuring the database and the provider.There were some costs to going this route: - You can not write the provider in TSQL. Either a database person needs to do some coding (me in this case) or you need to get a developer to help.- The database person needs to understand enough code to be able to discern what the programmers are trying to persist.- You need a way to define what needs to be persisted. This could be attributes in the code, special storage classes (that they own, not generated from the database), or an external document.- Developers need to follow a consistent pattern with their object model and abide by some limitations. These conventions can be fairly general and are not too hard for them to swallow because consistency is good on their side also.- All business logic and most data integrity constraints need to be provided in the domain classes. Most of these constraints work better closer to the applications and users that interact with them, rather than exceptions bouncing back from the database.- Our resulting database schema won't win any "normalization" contests, but it is not a "big blob of data" either. You can still understand it and work with it, even though object oriented concepts, like inheritance, can compel some denormalization.Some interesting side effects:- Communication with developers improved, in part because they saw the freedom they were given without having to "appease the DBA".- Instead of a flood of "change requests", DBA's were consulted more on design pattern changes and big changes in the model, before they were implemented, in order to determine if it would affect the provider. (Before the attitude was "It's just a database change, just make it happen." or “Here's how I think you should change the database.”)- Communication within the team improved in both directions. Part by necessity (new territory) and part because our goals seemed more in-line.- Application behavior changed from frequent, small trips to the database to less frequent requests for more data, which the application code managed and cached for longer periods of time. This should actually reduce the load on the database.Other notes:- Unit test coverage (and better yet Test driven development) of the data provider is CRITICAL. This is hard when you introduce a state machine like a database - lots of setup and tear down, but it is worth every hour invested.- You have less code to test compared to all the CRUD code that is generated in other architectures, but it is harder code to test and more critical. (A bug could affect multiple tables.)- Isolate your unit tests from the production tables and production classes that will interact with the provider. You don't want to mix developer or DBA bugs in your unit tests of the provider. Again, more work but greater peace of mind.- Create integration tests that help you flush out storage-related errors in the in the production classes and possible mistakes in the database schema.- If there is not an explicit way to determine what data in the domain classes needs to be stored, write tests to point out areas you might have missed.- Unit testing in Visual Studio (2005 Team Edition) is difficult and does not lend itself to test driven development. It's a shame the Microsoft tools haven't advanced further, but the testing is still worth the effort.- If you can automate the use of stored procedures, go ahead. I found that generating parameterized queries in the provider offered similar performance. (Kudos to the SQL Server Query Plan Optimizer Team for that.)When this project is complete, maybe I will present an article on the experience; benefits and pitfalls.A few things I am sure of already:- The end product will meet our customers' needs better than before. Agile is not about giving them a “visual fix” as someone else commented. It is about being able to "make it right" in the limited time you are given, by not wasting time creating what you think the customer needs. (In my case, the customers are the application developers and their customers, including sales and marketing.)- We will be able to make changes and enhancements to our application quicker than before, with greater confidence, and better test coverage.- Agile comes from intentional changes to your process and how you view your work. It will never occur “by accident”.Fri, 15 Feb 2008 07:51:08 GMTSteve Schmechelhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxHopefully this won't kick up too much mud. I agree with some of what Steve Schmechel is advocating (if not necessarily his approach in advocating it). In working with our developers building new systems, on the DBA side, I try to get as much of a valid database design based on the requirements as I can. However, we've hit issues where the requirements were so ill defined or changing so fast, that trying to maintain a database would have killed the project. Instead, we created about three tables that represented the core concepts of the app and let the developers drop XML straight out of their object defnitions into the database. Then, the requirements gelled a bit and we were able to add on another five tables, again with XML columns since we still didn't have adequate definitions for more. We've now grown the system out to about 40 or 50 tables, but some of these still have XML columns where we haven't refined the requirements. At no point have I simply slapped junk into the database without the full knowledge, that the stuff there was going to get changed as development moved forward. Now we're to the point where I can start performance and load testing with a high degree of assurance that the fundamental design isn't going to change underneath me. It works. BTW, Steve, sometimes, if an application is being designed to collect, collate, store, manage and report data, the database just might, might, be the foundation for that application. That's not to say the client, the app server, and any other SOA architecture layers are not just as important to the overall application, but the app is about data and the data is kept... in a database. Sorry, dude. It happens.That said, the key to any Agile project is direct communication between disciplines like dev and dba. Every time we've had a problem, the core of the issue was the lack of communication (or sometimes, bad communication). If you like, that's the real foundation of a successful app dev effort.Fri, 15 Feb 2008 06:50:13 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote][b]Steve Schmechel (2/14/2008)[/b][hr]Where I work we embed databases in our products. Often, before the user requirements are even fully understood, database developers and code developers (who know enough about databases to be dangerous) are busy discussing the database requirements and schema so they can "begin" their work. So maybe this idea of "As a database guy I tend to look at the database layer as the foundations for software development" rubs me the wrong way.[/quote]I'll say first that I'm often enough coming across as "all guns blazing" - so I understand how easy it is to very "extra spicy" into an answer... I was feeling a tad bit "extra spicy" writing the post a little earlier, so I'll go right ahead and say I wasn't trying to be harsh, and am hoping no feathers were ruffled.As to the quote above - there's definitely some truth to it, and it's a fairly common flaw to many projects I come across. A frequent poster on here phrased that problem very well with: [b]when all you've been given is a hammer, a LOT of things start to look like a nail.[/b] Walking in with a pre-conceived design is definitively not the greatest for a project, certainly before any of the requirements exist. One of the common gripes I have with systems running poorly is the vast amount of stuff that doesn't belong IN a database (or doesn't belong in that particular database anymore). If you're not going to read it, update it, search it or correlate to it, why is it still here? Why was it ever here?Thu, 14 Feb 2008 16:49:50 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxI'm sorry if it appeared I came in "guns blazing". I have read other articles by David Poole and normally I think he is right on the money. This time I think he missed the mark.The article has more of the flavor of a blog/opinion piece than a call for professional discussion.Where I work we embed databases in our products. Often, before the user requirements are even fully understood, database developers and code developers (who know enough about databases to be dangerous) are busy discussing the database requirements and schema so they can "begin" their work. So maybe this idea of "As a database guy I tend to look at the database layer as the foundations for software development" rubs me the wrong way.If your job is to maintain the a big OLTP database of financial data that software developers write against you probably won't have easier alternatives to offer them for the near future, so you will have to figure out how to be agile within those constraints. Maybe that is the audience the author had in mind.I know this is SQL Server Central (database work is part of my job description and daily activity). However, I read the "Central" as a "central place to get information about SQL Server". (Which it does quite well - probably the best! :) )For many people, SQL Server is one of many useful tools for solving problems and not "Central" to their identity. Information on how to integrate database development into an agile process is useful to those people also. Put yourself in their shoes and ask what they take away from the article "Accidently Agile". Not much I am afraid.Thu, 14 Feb 2008 15:47:23 GMTSteve Schmechelhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxA well written article, but this is exactly the type of thinking that has brought Development in America to an all time low and why ultimately businesses continue to seek external resources. Agile Development is definately a methodology that allows the customer to see more frequent results. From a Business perspective, that may be what your customer wants to see. However, what they want and what they need are often two very different things and this is absolutely an area where a customer's ferver for a 'visual fix' each couple weeks should be managed. The very best project managers try to balance the customer's excitement to see something against the need for quality and attention to detail. For those projects with no real competent technical project management and no layer inbetween the develper and the customer, Agile may be the only way to passify the customers regular need for that 'fix'. However, you are ultimate not serving that customer or yourself and you are exchanging true development quality for short term customer satisfaction during the development process.For me personally, I believe the Sales and Marketing parts of our industry have encouraged this approach because it makes more sense to them and unfortunately, we'll always have a set of 'experienced' people who buy into the hype and the cool word "Agile". While I'm certainly no advocate of a long drawn out waterfall model where you do 6 months worth of hardcore development before anyone see's you emerge from a cube, I KNOW a far better result will be achieved for a project that is managed by clear and early identification of MILESTONES at regular short intervals. Those milestones don't necessarily need to be some new screen that a customer can see, but are still identifiable progression points that at the very least, a develper and technical project manager can identify and agree on and measure.I'll completely agree that great team communications and regular measurement points are fundamental to a project and those aspects of Agile are points well considered for any developer. However, the precepts of Agile involving the complete end-to-end development of one small piece of the project at a time often defeats the goal of having a well thought out system archtecture with the necessary attention to system integration that great products display. You can say that you can overcome this by having a lot of communication, but in practice it doesn't work that way. For a set of software development tasks that have been repeated by develpers a few hundred times in their career, Agile makes a lot of sense. For the other 98% of the projects that most of us find ourselves doing, the process will ultimately work against a quality result. Brad BenhamSenior ArchitectMcKesson CorporationThu, 14 Feb 2008 15:42:55 GMTBrad B-642568http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxSteve Schmechel,Thanks for logging in just to crap all over the article, that time as not wasted. I'm sure everyone appreciates your snide comments and asinine POV. You remind me of a high schooler still caught up in what is "cool" and what is "not cool", as if that has anything to do with the right ways to develop software.I've been critical in this forum before, and I've even occasionally been critical of some of the things Poole has said. It's OK, his ego can take it; but for God's sake please keep things constructive!(To all Forum Members: I know, I know...don't feed the stinkin' trolls)Thu, 14 Feb 2008 15:39:08 GMTCalvin Lawsonhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxThanks as ever for your comments.Some of the books I've read on the subject do mention that house building is a bad analogy for agile development but I couldn't think of a more suitable one. The whole point of an analogy is to find a common point subject that most people can relate to and to utilise it to aid communication. An ORM layer for communication?:unsure:I am currently working on a project on which I have preached the agile gospel. The business people, the PMs, the programmers, the delivery managers and support staff all sat around a table having a face to face discussion and made a rapid choice in favour of a small, light weight project that would be designed to be extendable. There were quite a few points and counter-points made but the face-to-face element really worked.My role is now as a DBA as I have chosen to be a specialist in a particular area. Regardless of whether I were a DBA or not I would say it would be blindingly obvious that a data driven project is going to require a good database foundation.If you were talking about a project to harvest information from a web site and store it then I would say that the database layer would be of lesser importance than the harvesting part of the project.The one thing that the DBA role encourages is not to test the depth of the water with both feet!The move to agile development is a paradigm shift but having spoken with experience XP protagonists (backed up my own reading) you have to buy into it whole heartedly, you can't really cherry pick bits here and there or the whole deck of cards comes down. My personal opinion is that agile development suits object orientated programming, I believe it originated in the JAVA camp. Even for object orientated programmers I believe some of the techniques came as a shock. i.e. inheritance is bad, association is good. Objects should be open for extension but closed for change etc.As a final point one XPer pointed out that there are two sorts of itteration. If you see the deliverable as a drawing of a man then one draws an outline of the man on the first itteration and subsequent itterations add more and more detail until you get the finished drawing.The 2nd approach draws a part of the man in entirety and each subsequent itteration adds a new body part.If you subscribe to this site then you have almost certainly had to deal with a database that was put in place with the "it doesn't matter now, we'll fix it later" attitude. There are 1001 reasons why it won't be fixed later the least of which are the technical hurdles. I am currently liaising with 3 different triametrically opposed groups of people to get them to agree to do the investigation work to find out what the effects getting rid of a small amount of data that prevents DRI being added would have on their systems.To the business this is a non-issue as it has zero visiblity. To the DBAs keeping the database functioning is a mind-numbing and time consuming job. Had DRI been put in place in the first place the DBAs could be building the better mousetrap and devoting more time to the developers rather than acting as a bottleneck while they fix legacy problems.Thu, 14 Feb 2008 15:18:47 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxA top notch article as usual, Mr. Poole. Where I work it's all waterfalls....Thu, 14 Feb 2008 13:30:46 GMTCalvin Lawsonhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote][b]Steve Schmechel (2/14/2008)[/b][hr]If you dig a little deeper into agile development you may find that often the early parts of a project don't require a relational database at all. (Don't throw things at me!) It may just slow the development cycle down. But contributing your "data" expertise in other ways might be helpful in making a transition later - IF THE REQUIREMENTS SURFACE! If they never do, you will still have contributed something important to the project.[/quote]While that's certainly true - if it weren't going to involve a relational database, we'd be reading about this on AgileDevelopmentUsingExcelAsDataStoreCentral.com.:w00t:It's a shame to come in with all guns blazing, especially when making assumptions about the posters and what they "do for a living". It's also a shame you didn't catch the fact that David is now espousing Agile, albeit it with some reservations. After all - the job of the DBA is to make sure that whatever is being done on the data side is solid, and ultimately doesn't tear the rest of the house down.Like just about any methodology - Agile can be very powerful if implemented and run correctly. However - like any other methodology - a lot of bad implementations of Agile have also been advanced, often by folks with either faulty understandings of what Agile is about or those who have no care or understanding of some of the roles involved in such a project. Once such implementation is the Extreme Agile programming David mentioned, which more or less advocates the data design as being irrelevant or an after-thought, which then of course makes the job of those with the DBA title or role very difficult, unpopular and frustrating.The thing to remember about this is the person filling the role of DBA isn't necessarily being an A**hole when they're asking to look a little ahead. It's that (like Scott Ambler himself points out) the further into something like this - the harder/bigger continuous refactoring of the data gets to be. Making the developer's job easier at the expense of sending the data team through a never-ending loop of increasingly hard iterations to remodel/refactor the data is viciating the purpose of Agile to begin with (it's to save work for the TEAM, not help the developers and scr** the data side). I don't know when the last time it was when you tried to change the tire on a moving car - but it does get a little tricky.Thu, 14 Feb 2008 13:20:14 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxSteve, That is why David wrote the article; so we can have a professional debate on the topic. I for one don't know much about it but I'm being thrown into the hornets nest so to speak. I would like to know both the pros and cons of the agile approach. My gut feeling tells me to put up my dukes and get ready for a fight, but my experience with the agile approach to this point has been zero so I have no idea what to expect. My initial impression with the project that I am working on is that the developers and leads want to bypass certain database design planning and documentation phases that I deem critical to the design of a efficient and scalable database model. Your response started to go into some of the pitfalls of the agile approach. Do you care to elaborate? Like I said, this is meant to be a professional discussion so let's get to discussing so others (well, me really :)) can benefit. Having both the pros and cons in mind will greatly help me in knowing what to watch out for. Any input?Thu, 14 Feb 2008 12:50:41 GMTJohn Rowanhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxSaw this article's title on a news feed and I thought there might finally be some enlightened discussion on databases and agile development on SSC.Instead I found :- A DBA (who believes his databases are the "foundation" of all good projects) justifying how some cool, new agile buzzwords apply to him also. (Thus, he is cool also. Many other DBA's also agreed with him, so they must be cool too!)- Previous buzzwords and good practices dug up and equated to agile development buzzwords.- Crazy analogy regarding "Christmas dinner of the nymphomaniacs anonymous society!".- Opinion on the Iraq war as if HE knew the all requirements up-front. (Maybe a well thought out database schema would have helped our war effort.)- Final thoughts that have nothing to do with agile development.- Business as usual - keep making CRUD, but "prioritize" your CRUD.Please read [url=http://www.ambysoft.com/books/agileDatabaseTechniques.html]Scott Ambler's book[/url] for yourself, don't take Mr. Poole's assessment as the whole agile story. Some of the concepts in his book might push you out of your comfort zone. That is where the growth is.If you dig a little deeper into agile development you may find that often the early parts of a project don't require a relational database at all. (Don't throw things at me!) It may just slow the development cycle down. But contributing your "data" expertise in other ways might be helpful in making a transition later - IF THE REQUIREMENTS SURFACE! If they never do, you will still have contributed something important to the project.Thu, 14 Feb 2008 12:24:28 GMTSteve Schmechelhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxGreat article. I've been an agile proponent long before the term was invented. As a one-man-gang developer in the user world for a large part of my early career I learned that giving the end users something useful, quickly and then continually evolving it was the most effective approach and the most value for the business... and one's career - you become a god to the users. It lives on in all the users called analysts that build useful (to their group) tools that get the job done. They use things like MS Access and don't necessarily follow standards or document - but they get the job done while the traditional IT world is scratching their butt. Even as a department head I made sure I had my "guy" that could make things happen quickly.The trick for IT is to do the same thing on larger, team-sized projects with supportable tools, standards, etc. If you need an incentive to get on board, consider that agile done effectively is an almost ironclad defense against outsourcing or offshoring.Thu, 14 Feb 2008 11:17:26 GMTGreg Younghttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspx[quote][b]Loner (2/14/2008)[/b][hr] . . .I want to ask a question, does anyone work in a company that has a good development team (including project managers and developers) that works on the same goal, has a good relationship with customers and has good communication between the team themselves and other departments?I haven't found one yet, maybe just me!! If you do, let me know the company name, I am sending out my resume to that company immediately !:)[/quote]You maybe surprised and I know I will get a lot of flak on this, but in my 30-years experience the best overall development relationships I've seen was in the military (especially USAF). NASA also has a good handle on a team approach but that is because they have rewritten the DOD regs to meet their specific needs. But, possibly a good reason that government offices seem to have a better approach is that they are not profit driven and have deep pockets -- Care to enlist? Thu, 14 Feb 2008 10:05:40 GMTRon Kuncehttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxDavid, Im surprised you're so late joining the agile movement! But pleased nonetheless!I'm a huge fan of Scrum. XP is interesting, but is seriously rigid. By comparison Scrum is a very analog approach that can be sized to fit your situation. For example, they suggest 30 days sprints and I've had success shortening them to as little as 30 days.I agree that its counter intuitive not to plan for the future, but your analogy is flawed in my opinion. Software isnt the same as house building, the cost to refactor can be (not always) substantially cheaper than having to tear down a room to upgrade the foundation. In practice experience should play a role in what you decide to deliver, but I've learned to err on the side of leaving something out rather than risk putting one more thing in that I might not need. Too many projects fail because of sheer scope, take out all the extras and build something, then iterate.I've seen a lot of people dismiss agile as the 'flavor of the month' and I think they are missing out. Like any tool/process it can be used badly, but used well it maps nicely to how the real world works. Most of us need to see the software to figure out it works the way we need it to, we need to use it to learn what would make it better, and we all need to get in the same room to talk about it.Thu, 14 Feb 2008 10:02:41 GMTAndy Warrenhttp://www.sqlservercentral.com/Forums/Topic455538-60-1.aspxDavid - Great Stuff! Nice primer on Agile. You touched the highs AND lows of the approach.Your final points are critical, and just became ten times more relevant with the Visual Studio 2008 launch, and its LINQ integration. You'd best learn to get along and have an open channel between the dev's and the DBA's - or you'll end up with dev's writing a bunch of dynamic and Linq code just to "get around" the pesky DBA who's trying to keep a handle on performance. The DBA will then retaliate with dropping the service account servicing said application out of the database... and then a 2000-year long nuclear winter sets in, after the large meltdown that happens with both teams in the CIO office, etc....It's really important to remember that Agile is great, but it does have an end-goal or destination in mind. Like you - I'd have to say that the overal data structure still needs to be fleshed out from the start, and reviewed/adjusted during each iteration if need be.Thu, 14 Feb 2008 09:47:14 GMTMatt Miller (#4)