You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

10 Mistakes Fuseboxers Make

10 Mistakes Fuseboxers Make

In the last year, I've seen a great number of developers make the commitment to learn Fusebox - and for good reason: the Fusebox framework and the Fusebox Lifecycle Process (FLiP) give developers both a framework and a methodology that work well in creating Web applications. Even so, there are still many pitfalls that can trip up Fusebox programmers. If you're learning Fusebox, here are some tips on avoiding common mistakes:

1.   Asking too much of wireframes
The Fusebox Lifecycle Process (FliP) begins with wireframes. A wireframe is a skeletal application meant to engage the client in the process of discovering what is required. I love wireframes. I find them tremendously helpful in the opening stages of a project, when we're trying to find out what the client wants. They're also very useful as a sales tool; clients see them and get excited by the ability to actually point and click - letting them browse through a skeletal application.

But many developers, eager to get coding, treat wireframes as all that's needed to fully explore what clients want. Wireframes work best when treated like a booster rocket - essential in getting us "off the platform," but quickly becoming ballast that weighs down the project.

Wireframes work best when they're used to help jump-start the process of prototyping - the process of creating an HTML version of the finished application. Too often, I see developers treat the wireframe as a substitute for a prototype. This is almost always a mistake - one that, unfortunately, doesn't reveal itself until the very end of the project. Don't forget a basic truth of software development: clients can only tell us what they want after they see it. In short, wireframes aren't a substitute for prototypes.

2.   Omitting the prototype
This is perhaps the worst mistake we can make. It comes in two varieties. In the first, we completely skip the prototype altogether. "Don't have time," we tell ourselves. Years ago, I worked as a cabinetmaker. One of the wonderful things about that experience is that it taught me patience and respect for my material and my tools. If the temptation in developing is to start coding too quickly, the temptation in cabinetmaking is to assemble too quickly. Hey, it's fun! I want to see my beautiful cabinet, chair, or curio. I want others to see it, too.

In working with wood, assembling the piece early in the process means that you're working with a largish object rather than working with what are essentially flat pieces of wood. When you do that, things like routing, drilling, and planing become much harder and you risk ruining not only a single piece of wood (a sad enough experience), but the entire piece. After a few ruined pieces, you learn to be patient, to delay gratification, to trust in the process. There's a reason they call things like cabinetmaking - and coding - disciplines.

Before I learned this, I often justified my zeal by telling myself, "I don't have time for all this process stuff. I need to see what I'm building." After the heartrending pain of ruining a piece or the heart-stopping fear of almost ruining a piece convinced me to slow down, I put a sign up in my shop to help me remember. It read, "If you don't have time to do it right, how will you find time to do it over?"

If you find yourself saying, "I don't have time to do a prototype," consider this: the work of the prototype must be done prior to delivering the application. What people usually mean when they say they don't have time to do a prototype is that they want to do it while they're writing the code. This is analogous to designing a cabinet while you're building it.

In the second variety of Mistake No. 2, we do a prototype, but don't do it completely. We whoosh through the process, putting up "sample" pages; we start coding before we know exactly what the content will be - in short, we don't have a true prototype.

But all of those details must be decided at some point in the process. My advice on this is the same I gave myself when I wanted to rush to assemble a cabinet: do it right. Understand that much of the value in prototyping comes from creating a context in which the inherent messiness of finding out what the client wants can work itself out.

If you do the prototype right, you'll find out about key people who weren't in the initial meetings (despite your insistence and the client's assurance that all key decision makers were present). You'll allow the office politics to work themselves out on your prototype - not your code. Finally, you'll arrive at a prototype that both you and your client can agree is exactly what the finished product should look like. Then you can start coding.

How long should a prototype take? Of course, this depends on the application, but I find that almost universally, developers tend to cut the prototype short; the desire to start coding is great. In looking back at jobs I've done, I usually find that the wireframe/prototype phases take up as much as 60% of the entire job. I'm tempted to say that the longer a prototype takes, the greater the chances for project success. Certainly, I've never found myself in a "post mortem" saying, "Gee, I wish we hadn't spent so much time on the prototype."

3.   Not establishing acceptance tests up front
It's easy to start coding and - like assembling my woodworking project - it's fun. But when do you stop coding? When is "done" done? If you don't establish this up front, you're likely to find yourself forever chasing a moving goal line.

Did you build the application for a single machine, later to learn that the numbers of users would require a cluster? Did the client assure you they were going to use SQL Server, only to later (and without telling you) decide to adopt Oracle for all corporate projects? Did the client forget to tell you that the application must handle 5,000 transactions per second?

I've made some of these mistakes, so I can tell you that it is definitely not fun to try to convince your clients (after the fact) that no, this had not been discussed beforehand and that no, the application was not built for this. Make expectations clear: put them into the project documents right after you freeze the prototype. Determine the environment in which you run your acceptance tests and make sure that you have access to that environment while coding.

4.   Not using unit-testing code
Now I realize your code is flawless - a model by which to guide less-experienced coders. Mine too. But we do have to work in teams with other coders and those coders - well, they do make mistakes, don't they? If you don't unit-test code, you're going to find the flaws when you begin to assemble the project. At that point, finding out where the flaws occur is the old needle-in-the-haystack problem. Again, not fun.

Unit-testing code doesn't need to be difficult. I recommend building a simple test harness that creates an environment in which an individual fuse can run. This might include setting variables needed by the fuse, establishing state management, etc.

Your Fusedoc provides you with all the information you need to build a test harness, and I recommend building them and using them to test every fuse you write. These test harnesses can be saved and run at any point. This can be a great confidence booster when you're deeply into a critical project and could use a little encouragement. Oh, and since we don't want to make those other coders - the ones who make all the mistakes - feel bad, we might as well test our own code, too.

5.   Waiting too late to integrate unit-tested code
This mistake is easy to make. There's so much to do while involved in a project - especially a large project - that it's easy to defer integrating the unit-tested code until very late in the project.

I recommend that, if you aren't already doing this, you try having regularly scheduled project "builds," where you integrate all of the code. Typically, after I've identified the fuses and written Fusedocs, I create a simple stub that says something like, "I'm home.main and I'm not implemented yet." With this, I can do a project build from the first day. Now, granted, it doesn't do much, but it does give me a framework for integrating working, tested fuses. I can build the project at regular intervals.

Daily builds are great confidence boosters. They also serve to alert us to areas where problems may arise. It's become something of a joke that on any project, the first 90% of the project is done in three months, while the remaining 10% takes another three months. Or six.

The problem, of course, is that we were never 90% done. We developers are nothing if not optimists. Daily builds are also helpful when working in team environments. Rather than trying to get a teammate to commit to a deadline, why not just use daily builds to see exactly how far along the project is.

The rule I use is that all completed fuses are checked in by midafternoon. Another rule is that only one fuse is worked on at a time. This means that at any given point, I should be able to see how the project is doing. If someone needs help, it becomes clear at an early stage and saves recrimination and blame later on.

The best way to ensure project success is to know exactly where we are. Then we can make needed changes and the project can get back on track. Depending on who your client is, you may want to give them access to a daily build site. This can alleviate a good deal of client nervousness. After all, they have reason to fear if their project fails (as most do) and a partnership approach can make you both successful.

6.   Starting at the database
If omitting the prototype is the most serious mistake we can make, starting a project at the database is probably the most common. "Let's get started on the database schema," someone will say, and others readily go along. It seems to make such good sense. Besides, it's something we can do that feels concrete; we can show our managers the progress we're making.

I suggest that a better approach is to begin by identifying the conceptual components of your application. If, for example, you're dealing with a document management system, your conceptual components probably include a "Document" and an "Author." These exist quite independently of any database. In fact, a database exists only to provide a physical storehouse for these conceptual components. Beginning with a database is truly putting the cart before the horse.

Once you've identified your conceptual components, determine the various properties for each component. If, for example, my application has the concept of an "employee," I might identify its properties as employeeID, firstName, lastName, dateOfHire and so forth.

Part of writing good code is writing clear code. If you're taking your cue from the database - especially if your company has database naming standards - then you're likely to end up with variable names in your code like PRO_CDR_RTN. What does that stand for? Who knows? And once you find out, who will remember in six months?

Instead, you decide what your variables should be named. Make them clear so that in six months, you, or whoever is working on your code, will be able to tell the nature of the variable from its name. Then you can alias the actual database names so that they come from the database with the name that you want.

It's not just a matter of naming schemes. Beginning with a database creates a needless dependency. Coding can't begin until all the database issues are resolved. But in a complex application, this can take weeks or months. Do you want to wait this long to write your code? I sure don't.

You'll want to write code to work with the eventual database record set, of course. One of the great things about relational databases is that they always return tables (or relations in relational database lingo). What starts off as a seven-table many-to-many join gets resolved down to a simple record set. That means that you can use an artificially created record set and work with it while you're writing code. Later, you can swap out the artificial for the real thing. Your code won't break and it won't have to be rewritten.

I wrote a custom tag called QuerySim.cfm to help with this. You can download it at www.halhelms.com.

7.   Not using a standard
But wait - if we're using Fusebox, we're using a standard. How can this mistake apply to us? Surprisingly often; otherwise smart people recommend to others the practice of "adapting" a standard such as Fusebox. While the desire to put one's own stamp on something is understandable, it's often a mistake.

One of the great things about standards is that they are, well, standards. Having an "almost standard" won't help much when you run into problems and need help either debugging or finishing code for a project. And unless you want to be stuck forever maintaining code you've written, you'll want to write to a standard so that others can pick up what you've done quickly and easily.

Standards are especially important if you're working on a team. One of Eli Whitney's great contributions to the world was his demonstration that standardized parts could allow products to be built cheaper, faster, and better than the old practice of each person doing their own thing. Whitney was a genius; his advice is as true of coding as it is of manufacturing.

8.   Not using projects to learn new technology
You've noticed that technology is whizzing past you? Why not use your projects to help both you and your company by increasing your knowledge? Now, far be it for me to discourage anyone from going to training classes (since I offer them!), but I do encourage you to also use the project you're working on to do some experimenting. I'm not suggesting that you turn your project into a science project, but rather select a very specific and relatively small technology (or a small portion of a large technology) to play with. Besides, have you noticed that companies tend to send their best people off to training - people who have taken initiative and actively seek out learning experiences?

For example, you might decide to experiment with XML on a project. ColdFusion has some wonderful tags and functions that make this process fast and painless. Or you might decide to try implementing the Model-View-Controller design pattern on your application (or a small part of it). (I've written about the MVC design pattern on my site, www.halhelms.com.) If you're using a good methodology like FliP, you'll have time to do this without endangering the project at all.

A friend remarked to me recently that "the difference between a programmer and a plumber is the programmer's knowledge." If you don't invest in yourself - in your knowledge - you're likely to find yourself without current skills, putting both you and your company in jeopardy. So be strategic: select a specific area that won't consume an inordinate amount of time and go to school on it!

9.   Fixing problems
We've all done this one: pressure on, little time left, deadline looming, and we have a bug. What do you do? Why, reach for the can of Lucky Brand Magic Fixit Powder, of course. This may take the shape of finding someone who you think may know more than you, shipping off all of the code for the entire project with an accompanying e-mail that goes something like this: "My code isn't working. Please help! I've got a presentation in two hours!!! TIA"

Or you might find yourself commenting out variables that are giving you problems, or adding in variables just to make the code "work." Believe me, I am sympathetic. I know the frustration and panic that such a situation causes. But the solution is not reaching for the Magic Fixit Powder. Once simple syntax errors are resolved, you're not dealing with a bug. Instead, you're getting valuable feedback telling you that your understanding of the logic of your program is incomplete. That's all. The solution, therefore, is to gain a complete understanding.

How? Well, one thing I recommend without fail is to use Fusedocs to document your code. You can easily see what variables are supposed to be entering and exiting your code. Are they doing what they're supposed to? Use test harnesses to ensure that what you think is happening really is. You can set self to the value of a page that simply calls Dan Switzer's wonderful Debug.cfm custom tag (www.pengoworks.com <http://www.pengoworks.com>), which will give you lots of information about the state of your application.

The important thing to realize is that you're in a situation that is not a singular occurrence. For as long as you're programming, you're going to be dealing with code that doesn't do quite what you expected it to, so craft a long-term strategy. Isolate the problem, use snippets of code running in a test directory to make sure that each individual piece of your code works. The downside of this advice is that you are likely to end up getting those e-mails thanking you in advance for "fixing" someone else's problem!

10.   Not asking for help
Wait a minute. I just told you not to rely on others to save you. Now I'm saying that one of the deadly mistakes that Fuseboxers make is not asking for help? Well yes, that is what I'm saying. Do your homework, for sure. Isolate the problem so that you know exactly where the problem is occurring, but if you still can't figure out where the problem is, ask for help.

Innumerable times, I've found that printing out the code in order to go over it with someone else reveals the problem quickly. I know someone who has a stuffed animal on their monitor that they talk with when running into problems. The point is to break a mental logjam by changing the environment.

Programming, sadly, is often a culture of one-upmanship, where lack of knowledge is a sign of weakness and revealing any weakness is seen as shameful. That's bunk. Our job is to produce a successful software deployment, not to prove to someone that we're like Al Franken's character, Stuart Smally, who needed constant self-assurance that he was "smart enough, good enough, and - doggone it - people like me."

Like the ColdFusion community, where Fusebox had its start, one of the great things about the Fusebox community is its collegiality and closeness. The forums on the fusebox.org site offer assistance from people who are more than willing to help. Lists like cf-talk at Michael and Judith Dinowitz's houseoffusion.com are invaluable. I write an occasional newsletter that deals with software engineering issues. (Sign up at halhelms.com.)

Well, that ends our tour of "10 Deadly Mistakes." If you've got any others you'd like to share, send me an e-mail at [email protected].

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

@ThingsExpo Stories
DX World EXPO, LLC, a Lighthouse Point, Florida-based startup trade show producer and the creator of "DXWorldEXPO® - Digital Transformation Conference & Expo" has announced its executive management team. The team is headed by Levent Selamoglu, who has been named CEO. "Now is the time for a truly global DX event, to bring together the leading minds from the technology world in a conversation about Digital Transformation," he said in making the announcement.
"Space Monkey by Vivent Smart Home is a product that is a distributed cloud-based edge storage network. Vivent Smart Home, our parent company, is a smart home provider that places a lot of hard drives across homes in North America," explained JT Olds, Director of Engineering, and Brandon Crowfeather, Product Manager, at Vivint Smart Home, in this SYS-CON.tv interview at @ThingsExpo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
SYS-CON Events announced today that Conference Guru has been named “Media Sponsor” of the 22nd International Cloud Expo, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to gre...
The Internet of Things will challenge the status quo of how IT and development organizations operate. Or will it? Certainly the fog layer of IoT requires special insights about data ontology, security and transactional integrity. But the developmental challenges are the same: People, Process and Platform. In his session at @ThingsExpo, Craig Sproule, CEO of Metavine, demonstrated how to move beyond today's coding paradigm and shared the must-have mindsets for removing complexity from the develop...
In his Opening Keynote at 21st Cloud Expo, John Considine, General Manager of IBM Cloud Infrastructure, led attendees through the exciting evolution of the cloud. He looked at this major disruption from the perspective of technology, business models, and what this means for enterprises of all sizes. John Considine is General Manager of Cloud Infrastructure Services at IBM. In that role he is responsible for leading IBM’s public cloud infrastructure including strategy, development, and offering m...
"Evatronix provides design services to companies that need to integrate the IoT technology in their products but they don't necessarily have the expertise, knowledge and design team to do so," explained Adam Morawiec, VP of Business Development at Evatronix, in this SYS-CON.tv interview at @ThingsExpo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
To get the most out of their data, successful companies are not focusing on queries and data lakes, they are actively integrating analytics into their operations with a data-first application development approach. Real-time adjustments to improve revenues, reduce costs, or mitigate risk rely on applications that minimize latency on a variety of data sources. In his session at @BigDataExpo, Jack Norris, Senior Vice President, Data and Applications at MapR Technologies, reviewed best practices to ...
Widespread fragmentation is stalling the growth of the IIoT and making it difficult for partners to work together. The number of software platforms, apps, hardware and connectivity standards is creating paralysis among businesses that are afraid of being locked into a solution. EdgeX Foundry is unifying the community around a common IoT edge framework and an ecosystem of interoperable components.
Large industrial manufacturing organizations are adopting the agile principles of cloud software companies. The industrial manufacturing development process has not scaled over time. Now that design CAD teams are geographically distributed, centralizing their work is key. With large multi-gigabyte projects, outdated tools have stifled industrial team agility, time-to-market milestones, and impacted P&L stakeholders.
"Akvelon is a software development company and we also provide consultancy services to folks who are looking to scale or accelerate their engineering roadmaps," explained Jeremiah Mothersell, Marketing Manager at Akvelon, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
"IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
In his session at 21st Cloud Expo, Carl J. Levine, Senior Technical Evangelist for NS1, will objectively discuss how DNS is used to solve Digital Transformation challenges in large SaaS applications, CDNs, AdTech platforms, and other demanding use cases. Carl J. Levine is the Senior Technical Evangelist for NS1. A veteran of the Internet Infrastructure space, he has over a decade of experience with startups, networking protocols and Internet infrastructure, combined with the unique ability to it...
22nd International Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, and co-located with the 1st DXWorld Expo will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud ...
"Cloud Academy is an enterprise training platform for the cloud, specifically public clouds. We offer guided learning experiences on AWS, Azure, Google Cloud and all the surrounding methodologies and technologies that you need to know and your teams need to know in order to leverage the full benefits of the cloud," explained Alex Brower, VP of Marketing at Cloud Academy, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clar...
Gemini is Yahoo’s native and search advertising platform. To ensure the quality of a complex distributed system that spans multiple products and components and across various desktop websites and mobile app and web experiences – both Yahoo owned and operated and third-party syndication (supply), with complex interaction with more than a billion users and numerous advertisers globally (demand) – it becomes imperative to automate a set of end-to-end tests 24x7 to detect bugs and regression. In th...
"MobiDev is a software development company and we do complex, custom software development for everybody from entrepreneurs to large enterprises," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, discussed how from store operations and ...
"There's plenty of bandwidth out there but it's never in the right place. So what Cedexis does is uses data to work out the best pathways to get data from the origin to the person who wants to get it," explained Simon Jones, Evangelist and Head of Marketing at Cedexis, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
SYS-CON Events announced today that Telecom Reseller has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Telecom Reseller reports on Unified Communications, UCaaS, BPaaS for enterprise and SMBs. They report extensively on both customer premises based solutions such as IP-PBX as well as cloud based and hosted platforms.