June 20, 2011 at 5:30 am
I have a question for anybody using Agile as part of software development.
How do you find designing databases without complete specs ?
Do you rework your code often ?
Given an option would you switch to Waterfall model?
Does it really matter; since your using some kind of ORM, entity framework ?
Are you using a different approach when it comes to databases.
The reason I ask is coz agile is being adopted in a big way in my company and the transition has been mixed bag so far. Is it the same for everyone?
June 20, 2011 at 6:52 am
Agile development, when done correctly, is one of the most disciplined approaches to development I've ever seen. Yes, designing the database without complete requirements can be difficult, but in general, while working with a disciplined development team, it can be done and it can work really well. But, most of the time, agile is put in place because teams find requirements gathering hard and they want an excuse to skip that step, or because they have a hard time matching requirements to code and so want an excuse to be able to constantly change the code (refactor). This way leads to development hell. I saw an app go through Agile and it was redesigned, completely, about every 6-8 weeks, for two years. It never finished. So, it's a seriously mixed bag. Would I recommend the waterfall approach? Hell no, but only do Agile if you're going to do it correctly.
ORM is a completely different issue. Again, if done correctly, it can work pretty well. If done incorrectly (model first I would say is incorrect), then you end up with some of the ORM horrors that you can read about out there.
"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
June 20, 2011 at 8:48 am
I agree with Grant.
Agile done badly or misunderstood it can be a complete nightmare. Done correctly, it works like a dream and after the base schema is in place all other changes are minimal.
I've the "pleasure" of being in both situations.
June 20, 2011 at 9:03 am
Ditto.
Most of the problems with "Agile" are based on the fact that what they're really doing is Cowboy Coding, and calling it Agile in order to have a buzzword for it that sounds good on resumes. Actual Agile makes database development easy, so long as you remember that normalized data can be extended for future projects more easily and efficiently than "denormalized" data. (Again, most shops that "denormalize" are really just never normalizing, mostly because they don't know how. Actual denormalization is a science in and of itself.)
I've seen both.
I've been in Scrum meetings where the manager in charge asked people to assign difficulty and complexity values to project titles that were too vague to judge, without clarification or amplification, because "it's just an estimate". That's just a total misunderstanding of Scrum's purpose.
Actual meeting:
Manager: "The project is 'modify web site X as per requirements from public relations'. How complex and difficult will that be?"
Developer: "What do they need done?"
Manager: "Just assign a number. It's an estimate."
Developer: "I don't know what they want. Is it a lot of changes, or a few?"
Manager: "Just estimate a complexity."
Developer: "Okay. Seven."
That particular developer simply assigned 7 to all his projects from then on. The same manager defined "seven" as "more complex than "six" but less than "eight". Expected developer effort and time? "No, it doesn't work that way. Some might be a higher number because of how complex they are, even if they'll only take a few minutes, and some might take all week but get a lower number because it's really easy, just time consuming." Yes, he really defined it that way.
If "Agile" is implemented like that, you'll get the results you would expect from that level of stupidity.
I've also seen it done well. When done well, it simplifies and clarifies the whole process for everyone, and a lot gets done.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 20, 2011 at 9:40 am
We used a variation of this for weekly releases for well over a year, which included database design changes.
We could spend a few hours on db design, debating the changes that were needed, gaming potential future changes, and then implementing schema changes that allowed some flexibility in the future. It wasn't perfect, and we had to "undo" some changes over time, but not many. Mainly it was a regular extension of our schema to meet some needs, along with the addition of denormalized tables at times for reporting when we found the old schema didn't quite meet new needs in an efficient manner.
June 20, 2011 at 12:52 pm
I agree when done properly Agile is great for the developer , in fact I have enjoyed working in this manner coz it allows me to do just enough coding, Esp since most of our procs are simple crud operation. However I am quickly reaching a point where application developers now take for granted that the underlying data model can be changed to cover for scenarios they haven't handled leading me to worry that I'll have a poorly performing database in a few years time.
I push back only to get the reply that this is what agile is about 😀
June 20, 2011 at 4:20 pm
Jayanth_Kurup (6/20/2011)
I agree when done properly Agile is great for the developer , in fact I have enjoyed working in this manner coz it allows me to do just enough coding, Esp since most of our procs are simple crud operation. However I am quickly reaching a point where application developers now take for granted that the underlying data model can be changed to cover for scenarios they haven't handled leading me to worry that I'll have a poorly performing database in a few years time.I push back only to get the reply that this is what agile is about 😀
Oooh, that's a bad sign. When they start saying, "No, we can't do something you suggest, that's what Agile is all about. No, we can't possibly worry about performance, this is Agile." You're on the road to a bad, bad place.
"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
June 20, 2011 at 4:49 pm
Grant Fritchey (6/20/2011)
Jayanth_Kurup (6/20/2011)
I agree when done properly Agile is great for the developer , in fact I have enjoyed working in this manner coz it allows me to do just enough coding, Esp since most of our procs are simple crud operation. However I am quickly reaching a point where application developers now take for granted that the underlying data model can be changed to cover for scenarios they haven't handled leading me to worry that I'll have a poorly performing database in a few years time.I push back only to get the reply that this is what agile is about 😀
Oooh, that's a bad sign. When they start saying, "No, we can't do something you suggest, that's what Agile is all about. No, we can't possibly worry about performance, this is Agile." You're on the road to a bad, bad place.
Best bet is to make sure you're as insulated as possible when this starts becoming etched on the gravestones. Make sure EVERYTHING they interface is via procedures, so down the line, if necessary, you can completely retune under the hood with minimal effect on the front end.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 20, 2011 at 4:55 pm
Hm, guess I should just run down these questions.
Jayanth_Kurup (6/20/2011)
How do you find designing databases without complete specs ?
No different, really, then designing WITH specs, except that I can point to a document instead of a hundred emails when someone asks "Why does it color all the data blue here?"
Do you rework your code often ?
Not really. I've found most agile is new functionality. The only time I usually end up reworking code is when a module is being reworked on the front end.
Given an option would you switch to Waterfall model?
I personally prefer a mixed approach. Original design in waterfall, with expectation of eventual creep, and a decent layout from the start. It helps to get the ERD in place (generic design, don't go nuts) so that your modules aren't unexpectedly added on later, but you've got a decent idea from the beginning.
You can't etch it in stone, but it's nice to know where you know the large hooks are going to be.
Does it really matter; since your using some kind of ORM, entity framework ?
Oh gods, I'll just leave that question alone. Those two phrases send chills up my spine and I'd like to beat whoever decided that App and DB should directly integrate.
The reason I ask is coz agile is being adopted in a big way in my company and the transition has been mixed bag so far. Is it the same for everyone?
Every company that starts using agile always has a maturing period of about 5 years before they can settle into a solid pattern and learn from some pretty big mistakes everyone seems to need to make at least once.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
July 5, 2011 at 4:00 am
Sorry for not closing this discussion earlier , i was waiting to see if there was any more input.
Here's the update since I posted the topic.
Agile is great , but my team is not ready for it.
We have just finished redesigning two database close to 8 sprints since we started.
Looks like there's a lot of work to be done before we get in a good state with agile and database development, and it might as well be me than some poor shmuck who has to fix these databases.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply