Hal,
while I typically agree that standards should be in place in large enterprise
businesses, I also disagree with locking them into such
standards.
The
reason I say this, is that its part of human nature to take something, distort
it a little or allot and then roll with it. Example: If I where to tell you
quite a lengthy joke, and you thought it was funny enough to tell your friends.
So you would then hear my joke out again, and then turn to your friends and
repeat the joke, only you would add either your own touch to it or even expand
on it to add features that are more funny (i.e. sound effects, better use of a
sentence etc).
At the
end of the day, the core principal still remains in that the punchline is
delivered and the person laughs!
That
in a nutshell is why I feel sometimes these methodologies are the "holy grail"
as in a perfect development environment we would all use the exact same
structured code and all would be peachy keen. The problem is, the standard will
eventually get distorted and then we are back to the whole customisation of
something which originally started out in X and ended with
Y.
Introducing a standard into a development team, typically starts with one
person. That one person usually is the lead systems architect or "team leader'.
They read Fusebox.org or benorama.com, fall in love with a pattern that appears
to make sense, then begin to sell the upper management and the other team
members on the idea? Great, except how sure can we all be that this person has
fully read the documentation and importantly understands it.
Whenever read up on design patterns, I typically have these three things
roaming around in mah noggin.
1.
Learning Curve - How long will it take to introduce a new pattern, and what are
the potential drawbacks/pluses of shaping my developers into understanding this
new pattern
2.
Stability - A core pattern like MVC has proven itself, yes (don't disagree), but
its still in an evolving process when applying it to both FlashMX / CFMX. How
stable will this be, especially if I have a large application in
development.
3.
Enforcement - A key aspect to the pattern is also enforcing others participate
in its development, and in doing so you could starve your team members of key
ingredients needed for application development (innovation, creativity,
inspiration etc). It also adheres to the problem of a rogue team member not
fully understanding the rule book, thus requires two members of a team to drop
tools, hit the docs and re-learn/teach. Not good if you have pending
deadlines.
So to
summarise, all I am stating is, don't be so sure in locking yourself into a code
pattern, especially if you expect it to do all your core thinking for you, as
not all projects can adapt to such a theory, furthermore you work for the
company, you know its talent and past problems, surely you can evolve your own
process in development with snippets and pieces of various patterns (there's
tonnes of good ones out there, why lock yourself into just
one).
In
other words, use such code patterns / methodologies / code rule books as a
reference, and nothing more.
That's
my thoughts on the subject anyway :)
Scott Barnes
Snr
Developer
eCommerce Department
Tourism Queensland / Sunlover
Holidays
[EMAIL PROTECTED]
ph: (07) 3535
5066
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Hal Helms
Sent: Tuesday, 25 March 2003 3:44 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.comHere's a different POV: while it's absolutely true that "if it works, it works", there's something to be said for a standard. If you bring your laptop to my office, we're pretty sure that there won't be any problem with you plugging it in, because the plug adheres to a standard -- as does the laptop. Anyone who's traveled to other countries than their own may have had the experience of different plug standards. When that happens, things that we take for granted can become a big issue.I find this to be true in software development. I once worked on an ecommerce site for Sun Microsystems (solutionssite.com) in which the coding was done in one week by developers (who I had never met) who were working on the internet. (*Why* this had to be done in a week is a long story...) The reason it was possible was that we were all working to a known standard and friction was minimized.Years ago, I worked as a woodworker, building custom furniture in my one-man shop. I loved the independence and creativity that comes from doing "one-off" work and would not have wanted any system. The journey, as they say, was as important as the destination. When I moved from Boston to L.A. (talk about culture shock!), I ended up having a 13-person woodworking shop. We adopted a system for building cabinets and furniture that was invented in Germany. It made life enormously easier.I guess my point is that whether you want a standard or not depends on the environment you're in and what you're trying to achieve. For some people, a standard does them no good. For others, especially working on larger projects and with several members of a team, a standard is a godsend. I don't think there's a right or wrong answer -- just different answers to different questions.Hal Helms
"Java for CF Programmers" class
in Atlanta, GA May 5-9
www.halhelms.com-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes
Sent: Monday, March 24, 2003 6:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.comIn truth after much debate i can't see FBX and MVC working with CFMX. Its too abstract in my books.I'd stop looking for the holy grail of "how to" program in CFMX and simply makeup or adapt your experience into your own methodology. I think too many people are spending too much time chasing the holy grail and wanting another FuseBox rule book to judge your code by, when in fact if you have to constantly refer to the "how to's" within a methodology, your constantly going to second guess yourself and your abilities to develop.This is the time, now to develop, and hone in on your own ideas and concepts, the worst that can happen is someone will pass their opinion that your "methodology" sux, and in return you ask them for theirs and with no doubt, they too will have someone higher in the "OOP er33t" foodchain saying the same thing.If it works, it works! if it doesn't, rethink, restrategise and then go at it again.Scott Barnes
Snr Developer
eCommerce Department
Tourism Queensland / Sunlover Holidays
[EMAIL PROTECTED]
ph: (07) 3535 5066-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Davis, Eric
Sent: Tuesday, 25 March 2003 4:55 AM
To: [EMAIL PROTECTED]
Subject: [CFCDev] MVCF at benorama.comLink: <http://www.benorama.com/coldfusion/>
Word ver.: <http://www.benorama.com/coldfusion/patterns/MVCF.doc>Has anyone looked really hard at this one? What are everybody's thoughts on this?
I'm looking for a replacement to Fusebox 3 for MX - FBMX is too slow coming, and probably won't make much sense anyway (I'm guessing it'll be quite obfuscatory and rather difficult to implement the first five to ten times).
He's put together quite a presentation, and he about has me convinced, if only I can simplify the structure a bit. I'm trying to find the right methodology for my team here to use, and they're NONE of them big methodology-users.
Anyway, just haven't seen any threads about this, and wondered if you folks had anything to say on the subject.
Which of course you must; you always do. ;)
Thanks,
ecd.--
Eric C. Davis
Programmer/Analyst I
Georgia Department of Transportation
Office of I.T. Applications
404.463.2860.158
[EMAIL PROTECTED]
