Transcript How NOT to Fusebox a case study by Rey Muradaz [email protected] Presenter Background • • • • • 20+ years of computer experience CF developer for 6+ years Fuseboxer for 2+

How NOT to Fusebox
a case study
by Rey Muradaz
[email protected]
Presenter Background
•
•
•
•
•
20+ years of computer experience
CF developer for 6+ years
Fuseboxer for 2+ years
Currently CTO of a non-profit startup
Also an attorney specializing in
contracts/licensing for software
developers
Why Are We Here?
• “The best laid plans of mice and men
often go astray”—Robert Burns
• But there are steps we can take to
mitigate the damage
• As we’ll see, using a methodology (like
Fusebox) is a good step to take, even
when it’s implemented imperfectly
Presentation Overview
•
•
•
•
•
•
•
•
Project Background
Training is for Wimps
Defy Conventions
Silo Developers, Then Rotate
Don’t Provide Oversight
Don’t FLIP
No Code-Level Review
Breakdown the Barriers
Project Background
• City of LA ITA – rewrite of CF clienttracking system for service delivery—
conversion from spaghetti code/FB1 to
FB3
• City employees—2 project managers, 1
“utility infielder”, 1 DBA, 1 Sysadmin
• Contractors—7-10 CF developers,
various levels of skill/experience
Training is for Wimps
• Developers were quizzed re FB experience
during the interviews
• No real effort to ascertain skill level
• No training to ensure a common baseline of
experience or understanding
• Problem compounded by “cowboy coder”
mentality (“we learn everything we need to
know by doing, not by studying”).
Training is for Wimps
• “Learn by doing” is great for juniors who
are being mentored by qualified seniors,
but it’s an ineffective way to implement
a methodology in a team (unless you
have a lot of time and money to burn).
• Best practices have to be discovered or
invented, even if they already exist—at
best, it’s inefficient
Training is for Wimps
• Moral: Stand on the shoulders of giants (or at
least read their books)
• But even if that step is skipped, FB can still
make life easier in the team environment:
Relatively simple, so relatively easy to pick up,
even for cowboys w/o formal training
Provides a certain baseline of coding standards,
which serves as a common language that
facilitates group communication dynamics
Defy Conventions
• Many team members (especially the
most vocal) were young—hadn’t burned
any bridges yet (ever returned to your
old code a year later?)
• Some thought they had a better idea for
how to do things (naming conventions,
trailing slashes in path variables, etc.)
Defy Conventions
• Problem is two-fold:
Reinventing the wheel (and not always as
well as the original), which leads to
Additional effort required to
clarify/communicate the “deviations from
the norm”
• Moral: Conventions, like clichés, exist
for a reason—sometimes, it’s best to
leave well enough alone
Defy Conventions
• How does Fusebox help?
As above, it provides a rich internal language and
models to address a lot of these needs (can
bypass/ignore the kiddie hacks)
But it’s flexible enough to allow expansion or
deviation if needed
• No framework can do everything, but
anything is better than nothing (avoid
reinvention!)
Don’t Provide Oversight
• Conceptual challenge—PMs with less
understanding of the basics than their
staff (not a literal oversight issue)
• Problem—no referees, no one to
resolve internal disputes, no one to
provide overall direction
• Interactions become counterproductive,
team cohesiveness breaks down
Don’t Provide Oversight
• Moral: PMs need love (or rather,
education) too
• But FB helps, again in a couple of ways:
High-level—fbx_Switch/circuit.xml
breakdown creates a roadmap of the app
Lower-level—As above, many battles have
already been fought, so standards are
already defined, and can serve as models
Don’t FLiP
• FLiP—Fusebox Lifecycle Process
(design/architecture for app dev)
• Not strictly required, but leaving out this
step is remarkably dangerous in a team
environment
• Often leads to “code as you go,” which
rarely produces easy-to-integrate
components
Don’t FLiP
• Moral: Measure twice, cut once (if you
don’t have time to do it right, better
make sure you leave time to do it over)
• How FB helps:
Attributes scope—vars can be handled
regardless of source (though this can be
dangerous, esp. in CAYG dev)
Modular approach to FAs facilitates
integration
Silo Developers, Then Rotate
• Silo: We’re all special, each in our own
way (skills in layout vs. biz logic vs. SQL
coding)
• Rather than capitalizing on team
members’ unique abilities, have each
one be responsible for everything in his
module (most important—don’t try to
figure out who can do what well first!)
Silo Developers, Then Rotate
• Two types of problems
Application performance issues (bad
code/logic, inefficient queries)
Personnel performance issues
(dissatisfaction, frustration, etc.)
• Moral: From each according to his
ability, to each according to his need :)
Silo Developers, Then Rotate
• How FB helps
Modular nature of the fuse structures makes it
easy to dive in and fix individual problems (or
better yet, avoid them altogether)
Even if developers are siloed, the discrete nature
of fuse development makes it easier to focus on
one specific problem at a time—can help the
developer see the problem more clearly (and
realize when/where he/she needs help)
Silo Developers, Then Rotate
• Rotate: The most inexplicable part of
this project—periodically, people would
be rotated between modules (the
complete inverse of unsiloed
specialization)
• Creates significant inefficiency as
developers end up spending much time
catching each other up on the status
Silo Developers, Then Rotate
• Moral: Sometimes, change is not good
• But if you have to change, FB is on your side:
Structured approach to development makes it
somewhat easier to pick up the thread of the
process
Coding standards and naming conventions allow
developers to write consistently across modules
• It’s not a panacea, but it can make your head
hurt a little less
No Code-Level Review
(Don’t Look At My Code!)
• Potentially thorniest problem—adding up all
of the previous factors (no training,
conventions, oversight, or architecture)
makes it quite likely that bad (i.e.,
aesthetically sloppy and/or functionally
inefficient) code will be written
• OTOH, implementing this can be tricky too,
especially if no review standards are set (who
decides what’s “bad”?)
No Code-Level Review
(Don’t Look At My Code!)
• Moral: If you don’t know for sure that your
team is writing flawless code, make codelevel review part of your QA process.
• FB can’t solve this one (it doesn’t do
*everything* :), but it can point out at least
some of the problems (e.g., single-file FAs—
where are the queries?)
Breakdown the Barriers
(We don’t need no steenkin’ Encapsulation!)
• Tight links and dependencies between pages
often require parsing lots of code to figure out
the vars and scopes being referenced from
one to the next
• Tightly coupled code templates make the app
as a whole more fragile, especially when the
app logic traverses multiple templates
• Higher-order design strives to break down
monolithic elements to simpler component
parts, making testing, reuse and maintenance
much easier
Breakdown the Barriers
(We don’t need no steenkin’ Encapsulation!)
• Moral: Tight coupling has its place (I’ll leave
that to your imagination), but not in your
codebase.
• FB is particularly helpful in this regard,
because of the componentized nature of its
design and structure
• FB also helps smooth the transition to things
like MVC and OO because it helps
developers think in more modular ways
Summary
• Laziness, ignorance and incompetence can
make team application development difficult
• No framework will fix everything, but having
some kind of organizing construct is very
helpful
• Fusebox in particular is a useful framework in
suboptimal development environments,
because its inherent design helps to
overcome some of the more significant
challenges of team development, even when
it’s not done “by the book”
Resources
• Fusebox.org (http://www.fusebox.org)
• Fusebox: Developing ColdFusion®
Applications (Jeff Peters/Nat Papovich, New
Riders— http://www.newriders.com/)
• Discovering Fusebox 4 with ColdFusion®
(John Quarto-vonTivadar, et al.,
Techspedition—
http://www.techspedition.com/)
Thanks for coming!
• Questions/comments:
 Email me at [email protected]