Pick One: Open Methodology or Slave to Technology

You wouldn’t believe how many companies place their businesses at the mercy of their technology. You’d expect technology to be at the beck and call of business and its rules. Technology is supposed to enhance and optimize businesses, not govern and hinder. Sadly, that’s not the case.

Tech issues are fundamental. They affect return on investment (ROI). If you’re have bottom-line responsibility, ask yourself: Who’s in charge of your business, the people or the technology?

A few months ago on this site, Rebecca Lieb wrote:

Technology is no longer at the service of marketing; it defines marketing. This places marketers on an unprecedented learning curve… Programmers don’t want creative briefs, value propositions, or mission statements. They need minutely detailed specs.

True. The problem is several orders of magnitude larger than that.

A potential client (over $20 million in sales) whose site was developed by an outside firm didn’t even know if it owned the code. We suspect it didn’t, since the developer services many of this company’s competitors. What would happen if the relationship went awry? It doesn’t even have easy access to older order records.

Another company wants to increase search engine visibility and track and analyze visitor behavior using WebTrends. It also wants to make code changes to the shopping process but can’t because the cart produces dynamically generated URLs from .exe software. This makes it more difficult for some search engines to spider the site and to use their version of WebTrends. The company’s goal is to measure, test, and optimize pages to increase conversions and improve ROI. But it can’t meet these goals without a tech overhaul.

What do we advise?

First, marketers must understand development is not rocket science. They need to understand the developer’s methods and drive development through its phases to meet their needs. Second, your next development project, whether done in-house or outsourced, must utilize an open methodology.

Are you up to the challenge of developing a new Web site? Bet you feel like you’re about to navigate a minefield and somebody forgot to give you the map. If you follow the development process of wireframing, storyboarding, and prototyping, you can draw that map. These techniques coupled with open methodology will make development easier, faster, and cheaper.

So what is an open methodology?

Open methodology is an approach based on a known standard set of processes. The benefits to developers and clients are significant. A developer can accurately estimate the cost of your project. A client isn’t tied to one development team for subsequent versions. Any team employing the open methodology can bid competitively and understand work done to date. Some will argue they’re in a rush or under budgetary constraints. They’ll say, “We don’t have the time or resources to do all that planning and talking.” We always counter, “If you don’t have the time to get it right the first time, where will you find more time later to fix it?” This works. Both client and developer save precious time and resources!

One of the most exciting open methodologies is called Fusebox. It’s popular with development houses because its techniques can be applied to any development language. (I’m biased. Our CTO is one of the developers of Fusebox 3.0 standards.)

Fusebox employs three critical principles:

  • Modularity. A project is divided into small component pieces, each tightly defined. Because it’s modular, different pieces can be coded by different developers. All the pieces just “pop” into place.

  • Severability. Each module is self-contained and can exist on its own. Any references to other modules are set as variables so changes are easy to make. If references change, the module in question doesn’t have to be modified.

    Because modules are severable, developers can construct each simultaneously without worrying their work will conflict with something somewhere else in the code.

  • Clarity. “Fusedocs” are structured comments that document the interface between modules (“fuses” and “circuits”). They are so popular and clear, I see people using Fusedocs even when they aren’t using Fusebox! With this defining clarity at hand, each team working on a modular piece knows exactly how that piece will interact with others.

These principles give Fusebox and other open methodologies the power and flexibility to permit fast development. Modules of code can be dropped into place and work seamlessly. No module must be built in conjunction with any other one.

Result: a tremendous savings in time, money, and sanity.

Related reading