27
How NOT to Fusebox a case study by Rey Muradaz rey @ muradaz .com

How NOT to Fusebox a case study by Rey Muradaz [email protected]

Embed Size (px)

Citation preview

Page 2: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 3: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 4: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 5: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

Project Background

• City of LA ITA – rewrite of CF client-tracking 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

Page 6: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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”).

Page 7: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 8: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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 trainingProvides a certain baseline of coding standards,

which serves as a common language that facilitates group communication dynamics

Page 9: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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.)

Page 10: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

Defy Conventions

• Problem is two-fold:Reinventing the wheel (and not always as

well as the original), which leads toAdditional 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

Page 11: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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!)

Page 12: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 13: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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 appLower-level—As above, many battles have

already been fought, so standards are already defined, and can serve as models

Page 14: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 15: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 16: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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!)

Page 17: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

Silo Developers, Then Rotate

• Two types of problemsApplication 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

Page 18: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

Silo Developers, Then Rotate

• How FB helpsModular 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)

Page 19: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 20: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 21: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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”?)

Page 22: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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 code-level 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?)

Page 23: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 24: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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

Page 25: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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”

Page 26: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

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/)

Page 27: How NOT to Fusebox a case study by Rey Muradaz rey@muradaz.com

Thanks for coming!

• Questions/comments: Email me at [email protected]