|
Long version of response from article "New Approach ..."
Original Message: http://www.codeproject.com/aspnet/NewApproachToDesignWebApp.asp?msg=1371925#xx1371925xx
> but you are now heading towards the Agile development camp.
Absolutely. This is a technique with two feet in the Agile camp.
The large team and changing developers questions are good. In my current project I fought a bit of a battle getting the rest of the team to NOT TOUCH THE DAMN GENERATED CODE! I was mostly successful, but there was one critical object that was customized instead of subclassed, causing me to have to hand-modify code in about six places antime anything changes with it's design.
The technique doesn't fall apart if you only generate once, then stop using the tools and instead code by hand, but it certainly becomes less flexible. It really requires buy-in from the whole team that a certain section of code (I'll use the term "core") is not to be touched except in extenuating circumstances. If you can't get that buy-in it is difficult to build a project in this way.
>Requirements are necessary
Yes. The question is how do you get them and manage them.
> so that they can be signed off and then the
> developers have the backs covered
Absolutely not. I refer to this as "hiding behind the spec". This is what everyone does late in a project when they don't want to fix "bug X" or realize that a critical feature is missing. I've seen a lot of disastrous software pushed out the door because of the attitude that developers are absolved of responsibility for their code because they can point to section 3.23.48.3 of the functional spec.
> and the customer can be happy with the deliverable.
This last statement strikes at the very heart of SDLC's failures as a methodology for building software products. I don't want this to become a religious discussion about SDLC vs. Agile, but I'll veer there for a moment.
In over ten years of software development I have yet to see a single project where customer needs did not change between when the spec was signed off on and the product was ready. Process and Documentation heavy organizations simply make accommodating changes mid-cycle more difficult. This technique aids you in making high-level design changes and pushing them into code quickly with minimal pain and rework.
The only time customer sign-off becomes an issue is when you're developing for an external client. Then this becomes more of a contractual issue than a development issue.
> Use cases are necessary to understand the
> business requirements and processes.
Very true. Even Agile makes use of use cases for building and validating product and functionality. This technique I'm describing assumes defining the requirements and business needs to be external.
Your concerns about documentation are justified. If you are an organization that requires lots of doc this will probably be only a 30%-60% solution, only apply to the code, and only be as good as the developers can write. Complex interrelations between objects and more complete data flows are, as you say, more suited to use cases et all. It really comes to a point of evaluating your needs and finding the point of diminishing returns.
Documentation usually exists for one of two reasons: 1) To convey information, or 2) To satisfy organizational requirements. In the former, generating a large portion of the rote information will allow you to focus more time and effort on adding quality to the actual business-value portion of the application doc (and application). In the latter, no one reads it anyway, so who cares as long as it's "complete".
----
SPECIFIC ANSWERS
----
> What happens when the customer is not you?
Works just fine - discussed above as an issue of managing requirements.
> What happens when the project is large?
> What happens when the team working on the project is large
> and not always the same people?
Your questions are rooted in the fallacy that only large teams can build complex software. In my experience, large teams usually consist of 5-8 people doing actual work and 80 other people checking stock quotes and holding useless meetings to keep everyone on the same page. Short answer is the technique works much better with small teams.
> How do you make sure that the requirements have been met?
> How do you test?
Managing requirements is beyond scope. Perhaps I was a little cavalier in my discussion of how documentation is managed, but it is such a large topic that I wanted to keep it seperate from this article. The doc this referrs to will largely be restricted to design and API documentation by it's very nature.
Questions of how to test are the same as with any other development model. That is not solved by this technique, other than opening the door to some very rudimentary unit test generation. I prefer to integrate unit, performance, and acceptance testing into the development cycle, then perform a final short system test pass before ship, but that's me.
> How do you guarantee performance?
> How do you guarantee availability?
Pick a good generator. Several out there write code that does late binding and sometimes you'll see reflection - major performance no-no.
These questions are why I tend to maintain my own generators. It is perfectly possible to output code that will run under MTS and/or scale across servers. A few years ago I was doing this with an EJB application. For some applications, like reporting apps where you're dealing with large sets of data, this technique won't work. You'll want to bulk-load the data sets or perform processing in the database, but as I'm sure you know this is to be decided case-by-case.
> How do you perform user acceptance?
Put it in front of the user and see if they smile or cry.
Thanks for the questions and I hope the answers are useful.
----------------------
Chris Cole
-- modified at 14:07 Wednesday 15th February, 2006
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
