Avoiding costly rework

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.

DAMA

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

Miami JUG May 9th

If you happen to be in the area, we’ll have a nice opportunity for a roundtable discussion!

Topics and Speakers:

  • Agile Project Management Techniques by Jon Kern. We will discuss how to consider a simplified agile technique for managing a project, and how to blend it with classic “MS Project” style of management by Gantt chart.

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.

second first iteration

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:

  • getting their systems setup
  • understanding the best project structure
  • reconfiguring SVN
  • figuring out some of the flex UI issues
  • determining how to do CFUnit properly
  • etc.

The team was also new to

  • working collaboratively across multiple time zones,
  • doing an agile project,
  • doing a feature-driven approach,
  • having to estimate features,
  • doing domain modeling
  • considering a technical architecture
  • using tools like the confluence wiki, jira issue tracking, and IRC

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!

A layered approach with ColdFusion

currently working on a new project that is anchored in ColdFusion (CF). nonetheless, IMHO, the approach still should revolve around:

  • User Interface
  • Problem Domain
  • Data Management
  • Ext. System Integration

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.