February 5, 2012 at 5:20 am
The biggest strength of Agile Development is its biggest weakness as well i.e. ‘narrowed vision’. You don’t see the problem as a whole but as bunch of problems jumbled together, with assumption that each piece of problem is independent (or less dependent) of another. This assumption may & may not be true in real life.
I like agile development but my style is not Pure-Agile. I had limited the scope of agile development to SQL coding only. It doesn’t include Data Modeling. The reason is simple (and to follow the building analogy) to make the solid foundation & skeleton for the building first. Once I am convinced that the foundation can handle few floors weights without much adjustment, I don’t care which room of the building or which floor user wants to see first.
I would like to add here that few of my colleagues read about Agile DEV from BOL or some BLOG and blindly started following it. The projects been delivered to customers and customer was happy as well. But the delivery involved too much integration costs and over-time of DEV team. It’s not feasible IMHO.
February 6, 2012 at 2:50 pm
Evil Kraig F (1/22/2012)
Peter Schott (1/22/2012)
So overrides were put in place in certain places, the cart was modified, etc etc. Eventually this cart proc became about 30 pages long, and was so convoluted that processing a cart to completion could take up to 10 seconds. This was unacceptable due to ever increasing volume order.
A full redesign of the structure, incorporating the new modules into the core structure, allowed for a much fuller and less intricate system of maintaining the data. This took 3 months of pure dev work, no new features, no ... you get the drift. It wasn't possible to do this in small doses, we had to redesign basically from scratch for all the new modular components that had been included.
I'm all for agile as long as the time is taken every few years to clean up the mess it leaves behind.
It's not because you can't plan for the scope, it's because the very NATURE of Agile is planned scope creep.
This also applies to DEV's comment:
I would like to add here that few of my colleagues read about Agile DEV from BOL or some BLOG and blindly started following it.
Agile development is hard. I can't see how anyone could do it without a lot of study and intense effort, hopefully with someone who knows the ropes and can guide you along. (No, I'm not a consultant. But I wish we could hire one; it would help a lot.)
A wealth of Agile "best practices" have been amply documented. Not studying these or applying them to your project is a recipe for disaster. I find that most people who think that Agile can't work, or have had a poor Agile experience, did not apply these best practices and often apparently don't even know what they are.
It's the same as if a DBA failed to learn and follow best database practices (which are out there to be learned, and many people can help you learn them), then blamed SQL Server for their project disasters. Understanding SQL Server best practices takes a lot of time, study, effort, and experience. But if you're not following them, it's not SQL Server's fault. If you think that implementing the practices takes too much time for your situation, well, good luck to you--but don't blame SQL Server when things go poorly.
And no, if you end up with a 30-page code module (be it SQL or c# or any other code in your project), that performs poorly and is difficult to understand, you're not following Agile best practices. "Refactoring" constantly, aggresively, is the best practice that avoids this situation. If you get good at it, which takes study and experience, it will speed up rather than slow down development and keep code quality high. If you think that refactoring and other best Agile practices takes too much time for your situation, well, good luck to you--but don't blame Agile development when things go poorly.
It's easy to find good sources of information for Agile development in general, but I know of only one person, Scott Ambler, who specifically addresses the database portion in depth. He even has a book specifically about refactoring databases. There have been large, complex projects that have had success using his ideas.
February 7, 2012 at 8:37 am
GSquared (1/9/2012)
But what most developers mean by "Agile" is actually "Cowboy". Database development can be quite Agile. It creates a horrible mess when it's done Cowboy-Coder style.
Eloquently stated sir.
I've seen a few of these cowboy designs. The thing that amazes me is it really doesn't take much longer to come up with a real design Vs. a hack. Any disparity reverses itself when you factor in the countless man hours needed to support the cowboy design (fixing bugs & hacking it even more to add features).
The probability of survival is inversely proportional to the angle of arrival.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply