There have been some discussions around data modeling and the more costly impacts of database changes.
Doing the right amount of up front work precludes doing the costliest of
refactoring.
Doing enough quality modeling of the domain up front usually makes it
easier to accept change -- and to find where the change "goes."
Making a clear distinction between roles of the different software
artifacts (ui classes, business layer services, domain classes,
persistence management layer, DAOs, etc.) and how they play
architecturally in the implementation, also helps to make it easy to
figure out the impact of a change and where to make the changes.
however, if you have crap for architecture and widely-varying approaches
in different parts of the app, and all sorts of logic spread into the
database (like stored procedures doing business functions that could be
done in objects), then you have crap.
data folks being a "bit defensive" to me says i have to pay more
attention to what i do upfront. if it is costly to do certain parts of
development, then i will adjust my techniques to account for that. i
will have the team work a bit harder, possibly, to ensure that we don't
thrash the expensive parts of our construction costs.
In Dan Paolini's presentation, he likened Agile to the following:
Hmmm.... Nice! Poignant. Elegant.
So Agile is unethical, dangerous, capricious, and can't do math eh?
That was what we were going for in 2001. Now you've gone and exposed us!
Initially, we "lightweight methodologists" had gotten together in virtual ways (ward's wiki) and were discussing our points of view on how best to completely sabotage our customers. After all, the traditional methods weren't doing a good enough job!
Instead of Unethical Software Engineering Rules Programming (USERP) Manifesto, I suggested we hide our true identity by using a term I borrowed from my fighter aircraft research: Agile! That way we could be more sneaky like enron and tyco -- which we greatly admired.
Besides, waterfall failures were so passé... canceling projects after 10s or 100s of millions. Delivering the wrong thing too late for the business. Yawn. That's more like the Valdez Tanker Spill... slow and rumbling disasters. The Titanic was more cutting edge and agile -- especially since they didn't have software back then to screw up their control systems. They were only looking a short distance ahead and had no idea what their long-term goal was. Except for the port of call. That they were steering towards form Day 1, with frequent feedback and course corrections, I'm sure more than daily.
Oh, but wait! The Titanic was the culmination of incredibly huge amounts of BDUF! And it still failed? I'm confused now. Wasn't the Titanic "planned, architected, and designed properly?" Too bad they couldn't tell if it was going to fail early on in that process. Would have saved lots of lives and money, and spared us the movie.
Scott Ambler shared this link
agile schmagile...
The first slug of slides (which i have not gotten past yet) pointing out realities of some development efforts being lousy has nothing to do with agile and everything to do with people doing a lousy job at software development. News flash: anyone can screw up doing a project or misinterpret principles of development. Is that somehow the fault of the Agile Manifesto? I propose to consider it be the responsibility of the people involved...
If I get the stamina to respond I will, but here is just one stupid example:
"Who’s definition of ‘working’ shall we use, since we don’t have any requirements to
meet?"
It would be like me saying:
"Why bother getting the DBA involved because all they will do is screw up the design by ignoring the domain model and over building the data model to meet all sorts of needs not yet defined. And worse, they screw up all the class names with stupid prefixes."
DUH!
I am going to work to respond and not simply react... my guess is i will eventually find good words of wisdom in Dan's presentation once i get past the incorrect binding of stupid non-agile development habits as being how agile projects are all run.
I wonder how many properly run agile projects Dan has been involved with personally? My bet is zero. Dan?
I personally preach against all that you incorrectly attribute to "agile" --- DUH
Why just the other day, I even created a page on the project wiki for standards, and it started with database standards, believe it or not! And these were proposed and sample in form... i asked for the database guy to chime in with whatever standards they were using.
Hang around sometime. We may not be quite as stupid as you think.
If you happen to be in the area, we'll have a nice opportunity for a roundtable discussion!
Topics and Speakers:
Speakers Bio:
Jon is passionate about helping clients succeed in delivering business value through software development efforts. His varied career has spanned jet engine R&D through centrifuge-based flight simulators, to being an object-oriented evangelist through the 90s and his work with the Agile Manifesto for Software Development in 2001. Many credit him with much of the success that TogetherSoft enjoyed during his tenure with the UML modeling/ development product and the professional mentor group he founded.
Jon works with teams to solve challenging development projects for the stakeholders. From analyzing the approach, to helping provide solutions, to mentoring teams -- and all points in between -- Jon routinely has significant impact on the projects he works on. Often with a team of experts from his friends at immuexa.com, the small teams of 3-6+ people supply a quick-hit ability to solve problems and deliver results. Projects routinely see high quality solutions in half the time, and typically leave the local team in place, mentored on OO and agile, and excited.
we had our second iteration kickoff today.
the first iteration was a bit premature -- but i knew that. there were still issues with the team's preparation:
The team was also new to
Nonetheless, nothing like a deadline and an exercise to help bring things to the foreground!
We allotted only 25% of their available time to be allocated as ideal engineering hours for the task estimates. About half of the iteration or more was taken up by issues with infrastructure, set up, etc. Surprise, surprise, we got 17 of 31 issues completed. about 50% -- which stands to reason.
there are a couple of lingering technical issues as we start this iteration. we rolled over the unfinished issues for iteration 1, added a new round of follow-on issues, and went through an estimating and assigning session.
progress is being made on many fronts. now to see some features roll off the assembly line in a bit more predictable fashion for this milestone!
currently working on a new project that is anchored in ColdFusion (CF). nonetheless, IMHO, the approach still should revolve around:
we have worked up some initial domain models as we built up the feature list. in the land of CF, we are able to build Value Objects to represent our domain. For persistence, we can use simple DAOs for CRUD, and Data Gateways for more complex SQL machinations.
from the services end of things, we'll surface the business functionality as delegates/business facades to be invoked over the wire by the Flex clients.
just getting into it... but i'll keep you posted on how well things get on with this approach.