1993

The World Wide Web debuted to the public, for free, 20 years ago today. Yup, only 20 years ago. Here was the first website, which has been re-released by CERN for this occasion:

1996

Our founder, Alex Schmelkin, made his first website for Hofstra University 17 years ago. Check it out:

2002

The year Ai’s created its VERY FIRST WEBSITE. The lucky client? DonorsChoose.org

2003

We developed our first ecommerce website for FragranceNet.com. FragranceNet.com is ranked 153 on the Internet Retailer Top 500.

2013

That’s now! This month we launched MyRingPop.com, with e-commerce and custom product configuration. Voila!

Any guesses what websites will look like and what technologies will be important in another 20 years?

Jealous? Buy your own Custom Ring Pops at MyRingPop.com.

A lifetime supply of Ring Pops – courtesy of the fine folks at Topps.

Setting up for the MyRingPop.com launch party

I recently shared some thoughts with Directors & Boards Magazine on the critical importance for corporate boards to recruit Directors with backgrounds in technology and digital media.

On the topic of recognizing the importance of digital in today’s business model:

Corporate boards that lack leaders who are fluent in digital media are doing their shareholders a disservice. Every industry, every corporation is being disrupted by the ever-shortening distance between brands and their consumers. It’s not enough for a board to expect management and their reports to understand the latest developments in social media, mobile innovations, and marketing. Instead, such strategies should be discussed at the highest levels, directly between the board and management, and incorporated into a company’s long-term plans.

Read the entire article on recruiting Directors with technology experience to corporate boards.

Ai’s office was proud to play host to GetTaxi’s Israeli tech startup gathering and Ron Huldai, the Mayor of Tel Aviv, this afternoon. A wide array of Isael-based tech companies met in our uber-comfy Sofaplex to discuss technologies ranging from mobile payment systems to personalized video advertisements their firms have developed.

Host GetTaxi is an Israel-based smartphone app whose New York location is managed out of Ai’s NYC office. Their app, which is currently live in Tel Aviv, London, Moscow and St. Petersburg, digitally hails taxis for 10,000 rides per day. GetTaxi is planning on launching its New York City service this year.

Other companies that displayed their wares at today’s meeting included: Wix, Pango, BillGuard, ADagoo, Mobil, LoyalBlocks, and Eyeview.

“Tel Aviv is home to 700 startups,” said Huldai ,”and we are excited by those that spread their branches to include the Big Apple.”

Josh Levine, Ai’s Chief Experience Officer, presented his session: “UX & Design: When Does One Trump the Other?” with Jordan Lustig, Director of Product Management for Saks Fifth Avenue.

The presentation explored the delicate balance and interplay between User Experience and Design in e-commerce website production from both a designer and retailer’s point of view.

Download the presentation here.

Construction of the Gatun lock, Panama Canal, 1912.

If you ask me how long it will take to do a familiar but substantial task, chances are I’ll give you a wrong answer. I will tell you, “That will take me two days,” when in fact it has never taken me two days. Perhaps it has always taken at least three, and usually four. But I’m unable to think accurately enough about the past to reach this conclusion, especially if you ask me directly. This is a rough explanation of the Planning Fallacy, one of the most fascinating and pervasive cognitive biases. We all suffer from it when we make estimates, and it is especially acute with off-the-cuff estimates intended for an audience. We feel the pressure of judgment on our estimates, and unconsciously seek approval by providing optimistic and incorrect numbers.

Hofstadter’s Law formulates the cognitive puzzle embedded in this fallacy:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Knowing about the Planning Fallacy isn’t enough to escape its influence.

Multiply this estimation inaccuracy by a large number—a factor determined by the complexity of the project—and this accounts for the primary reason that most projects fail to deliver on time. The “padding” that individuals, their managers, and their managers’ managers regularly add to work estimates is often whittled away during the piecemeal negotiation that falls between the estimation and commitment phases, leaving the original, overly optimistic estimates.

The bottom line is, and always has been, that estimates we make at the beginning of a project, because they are made in ignorance of the future, and because the Planning Fallacy distorts our thinking, all too often range from Pollyannaish to tragically mistaken. See Jim Benson’s Why Plans Fail for a concise and revelatory spelunking into the depths of the planning mind.

When we allow a project to be bound by our initial estimates, whether they were constructed with the best of intentions but subject to the Planning Fallacy, hampered by a misunderstanding of the requirements, distorted to meet the demands of the client, or simply doomed to irrelevance by the inevitable array of exigencies that befall every project, we force reality into an inappropriate container.

But we still need to execute on the project plan, whatever its condition. Content strategy, UX, information architecture, conceptual design, applied design, rounds of approval and review: these initial phases may expand as they attempt to capture the entirety of emerging requirements, and subsequent phases become necessarily further compressed.

The technology team deals with this compressed time frame by (a) being galactic geniuses (I am not biased) and (b) making compromises. Compromises can be deliberative and explicit, panicked and hidden, or half-heartedly considered and partially documented by inline code comments.

Some compromises are driven by a clear-eyed assessment of the border between Minimally Sufficient and Fancy. Although programmers are famously lazy, they are just as often driven (by Larry Wall’s #3, Hubris) to engineer the perfect solution where an adequate one is the optimal path. Choosing adequate over perfect means that we can reserve precious engineering time for the hairier tasks, or the unexpected but inevitable road bumps that put further pressure on development schedules: bugs in the platform or a crucial module, foibles of the programming language, unexpected complexity in meeting a functional requirement, iterations between UI design and software implementation, and so on.

We can expect road bumps, but we can’t plan for them. If we start a development cycle with an unrealistic schedule estimate, then we can just expect to be late from the start. In an atmosphere like this, ill-considered compromises are almost inevitable. These compromises constitute the primary source of technical debt introduced to a new code base. We can only hope that the developers at least take the time to add TODO-style comments to mark the code they’d like to refactor in the future.

You can find these later:

$ find . -type f -exec grep -i todo {} \;

(Try that in Magento Enterprise 1.12’s app/code directory: 171 of them. It happens to the best of us.)

There are basically two strategies here:

1. Minimize bad technical debt* and stress by renegotiating the release schedule
2. Plan to address bad debt in a subsequent release

#1 is vastly preferable. #2 is only possible if you can isolate and track the debt, and push off developing new features in favor of addressing old problems. This often requires a heightened level of transparency between the technical and business teams. Otherwise, building new features on top of crufty, debt-ladened code will hinder progress on the features, slow your development velocity, increase the overall error rate, and reduce your ROI by alarming numbers.

How to minimize contact with this Planning-to-Debt problem: Plan to revise your estimates. Regardless of your project methodology and how it incorporates estimates, educate all project stakeholders as to the reality of estimation, if it’s not already abundantly clear. Help the team to understand that the process of estimation is more valuable than the estimates it produces.

* “Bad technical debt”: Not all technical debt is bad. Another useful distinction is short-term versus long-term debt.

Ai is back in Orlando, Florida, and we want to see you!

We are at the Internet Retailer Web Design and Usability Conference at the Omni Orlando Resort at ChampionsGate. Our booth is #400 in the Conference Exhibit Hall, and we are discussing the latest and greatest in web design through tomorrow, Wednesday, February 13.

IRWD focuses on the latest strategies to communicate product quality, brand identity and increase conversion rates on the web.

Josh Levine, Ai’s Chief Experience Officer, will be presenting a session titled “UX & Design: When Does One Trump the Other?” tomorrow at 1:30pm with Jordan Lustig, Director of Product Management for Saks Fifth Avenue. We would love to see you there. The presentation will discuss how to balance the best of user experience and design from both a designer and retailer’s point of view.

]]> http://www.alexanderinteractive.com/blog/2013/02/come-see-ai-at-irwd/feed/ 0 http://www.alexanderinteractive.com/blog/2013/01/magento-core-bug-unable-to-save-config-changes/?utm_source=rss&utm_medium=rss&utm_campaign=magento-core-bug-unable-to-save-config-changes http://www.alexanderinteractive.com/blog/2013/01/magento-core-bug-unable-to-save-config-changes/#comments Tue, 29 Jan 2013 16:16:41 +0000 Matt Holford http://www.alexanderinteractive.com/blog/?p=6778 Read Full Post]]> In the latest releases of Magento Community and Enterprise Editions (1.7.0.2 and 1.12.0.2), there’s a core bug that throws a PHP Notice when you try to save certain configuration screens. For instance, when saving from the Advanced tab:

The code in question is this:

<?php

/**
 * Get field backend model
 */
$backendClass = $fieldConfig->backend_model;
if (!$backendClass) {
    $backendClass = 'core/config_data';
}

?>

The bug report on Magento is here (registration required).

It’s curious that both the bug report and this discussion suggest you add

<?php

unset($backendClass);

?>

before this code block. Strange, since this code block explicitly assigns new values to $backendClass one way or the other.

This solution has worked for us — just some additional value-checking:

<?php

/**
 * Get field backend model
 */
if (!is_object($fieldConfig) || empty($fieldConfig->backend_model)) {
    $backendClass = 'core/config_data';
}
else {
    $backendClass = $fieldConfig->backend_model;
}

?>

I’d be curious to hear any arguments about what memory-management magic the explicit unset() call would invoke here.

Gist file here: https://gist.github.com/4664829

If you work on software, you most likely use a bug tracker to track defects, manage development tasks, and plan releases. The collection of tickets, open and closed, is a data set that doubles as a repository of institutional memory about your software: what components have been the most complex (i.e., have spawned the most bugs)? Who worked on what, when? What issues did the developers grapple with over the course of delivering on a requirement or resolving a defect? What compromises did the team decide to make (or, worse, what were they forced to make) to hit a deadline? What’s never been fixed, left to fester in a dark corner?

You may have other documentation sources for your software: end-user docs, developer handoff docs, long and tortuous email chains, wiki pages, and inline documentation in the code base itself. But, if consistently used, a bug tracker can show the underbelly of the development process in remarkable detail. It is here where teams can probe their work history to uncover decisions and issues that we can categorize as technical debt. (Example: Open the longest-active project in your issue tracker, and find the oldest unresolved bug. Behold.)

And once we have classified bugs as technical debt, that can be its own component—a component we should consider as first-class, along with mission-critical and user-facing components. Unlike other components, which must be maintained and improved, technical debt must be managed. It is an emergent component that we should assume will always be present in a system.

This kind of emergent debt is what happens when we gain insight into the longstanding problems in a system, when we start to trace one problem back to a past decision, well-considered or otherwise. We can find the areas where we have built workarounds over the compromise and complexity we originally injected into the system.

And the status of these issues as bugs means that we have already filtered out most non-harmful technical debt (I am squarely in the “not all technical debt is bad” camp): if the team implemented a shortcut that never caused or registered as a problem, it’s not in the bug tracker to begin with.

Just as importantly, in some situations we can choose to split these bugs into actionable sub-tickets, and cast off the rest. If, for instance, an old bug has to do with a component that has architectural flaws, but which is used more and more rarely, we can choose just to address the surface problems, knowing that the underlying debt in this instance will get zeroed out when we finally sunset this component completely (this must be a real plan, of course, such as a replatforming project in the not-too-distant future). So we break out the surface problems into discrete bugs, and then we can close the hairy old bug and pat ourselves on the back.

For example: an e-commerce system has a year-old bug on the books concerning user feedback in the checkout flow. The underlying problem has to do with the poor integration of the payment gateway. You, the tech lead, are fresh from a meeting where the business owners agreed to a payment processor with a much cleaner integration. The transition is a few months away still, but all the bug-spawning cruft of the old integration is now scheduled to disappear. You can now split this bug into some constituent sub-bugs that make cosmetic changes sufficient to address the symptoms of the original bug report. You can also close out the year-old bug with references to the cosmetic bugs and the impending payment system change. Were a new payment system not in the works, this band-aid approach might seem an irresponsible way to manage the technical debt underlying the original bug; in the new reality, though, you’ve decided to acquire short-term debt that has a definite lifespan.

(Side note: this example highlights the breakdown in the strict financial debt analogy. Technical debt can, in some cases, just magically disappear. Don’t try this with your credit card.)

We can also use the bug tracker explicitly to expose and track technical debt as we take it on or discover it in a system. This is especially useful when a developer needs to surface and memorialize decisions, shortcuts, quandaries, and TODOs in order to implement a feature. Being able to enter bugs related to the development process, and to categorize them as debt and not feature bugs, allows the developer to stay focused on the implementation, while making the process more transparent and contributing to institutional memory.

I’ll explain by example. Let’s posit a developer: Cold cup of coffee perched dangerously on the edge of the desk, sitting back in an office chair, wearing overpriced headphones, perhaps sweating a bit, wrestling with the latest in a series of hairy performance problems near the end of a development cycle. The task at hand is to deal with a slow page load. In the process of tracing the execution chain, the developer runs into a run-on sentence of a method that cries out for refactoring. It’s also probable that some of this logic will be useful elsewhere, once it’s extracted from the monolithic method. It’s also clear, however, that this method is not impacting load time—for the purposes of the task at hand, it’s more of an itch to scratch.

Thanks to the GTD methodology, we know how to deal with these itches. The answer is not to lose focus on the task at hand, but rather to record the unrelated task and file it in a place where we can address it later. To do this, we need a simple filing method that allows us to categorize the new task efficiently, so that task creation is not itself a distracting activity.

Clearly, our developer needs to get this into the bug tracker. It takes thirty seconds to create a task called “Refactor Ai_Checkout_Helper::doThings().” The tech lead should provide a single, simple tag (or label, depending on your issue tracker’s terminology) for these debt-repaying tasks: shouldfix, refactor, or technicaldebt will work. The goal is to create a two-step method for recording technical debt-related bugs that developers find in the course of doing other work:

1. Enter minimal notes, including file and line reference.

2. Label as technical debt.

It would be fun to monitor activity logged against this label in the heat of a project (e.g., an RSS feed attached to the label), as you’d have an equivalent of the fantastic “WTFs per minute” quantification of technical debt.