pixelslave

Looking back over my posts of the past year has made me realize a few things. The first thing I realized is that we keep making the same mistakes over and over and, as an organization, we're not going to change. The second is that unless there are some changes in the management team we're doomed to repeatedly explore the continuum between mediocrity and outright failure. I've learned that giving it my all and aiming for excellence not only goes unappreciated but also makes me unpopular with both management and my coworkers. With those insights  in mind, I've come up with the following resolutions for 2009:

1: Duck and cover. I will keep my earphones on and my head down as much as possible. No good comes from getting involved.

2: Zip it. I will keep my opinions to myself. No one wants to know what we're doing wrong and no one wants to fix anything. I'm not only wasting my breath by trying to change our processes, I'm potentially risking my future with the company by speaking out.

3: Celebrate the 40-hour week. No more weekends and evenings for me! From now on my coworkers will be able to set their watches by my arrival and departure.

4: Invest wisely. Being personally invested in the success of our projects and, by extension, the success of our company put me in an unpopular minority and caused me a huge amount of unhappiness and frustration. My new take on investing in the company will be limited to my stock purchase. The company will eventually rebound from the disasters that have plagued it this year and, hopefully, the thousand or so shares of stock I bought when the price was in the toilet will increase in value enough to make up for the bonus I didn't get as a result of those failures. If I can't prevent disaster at least I can try to profit from it.

5: Improve my value as an employee. Like most of my fellow employees I will devote a full 3 hours of my work day to doing actual work. But unlike the three developers who sit nearby and do daytrading, or the five members of "Serena's" team who pass their hours in a non-stop gabfest, I'm going to use those four extra hours to improve my mind. I'm going to build my skills and learn new ones so I'll increase my value to my employer. My next employer, that is.

Just as what goes up must come down, what goes into the branch must eventually be brought to the trunk.

When the decision was made to begin development on the new European design for the checkout and registration flow the code was branched. All development was done in that branch. The thought behind an early branch was that there was so much new code coming in that it would destabilize the trunk. More to the point, it was decided that in order to proceed at the required pace the developers would have to be free from concern about the other sites using the trunk code (our high-profile domestic B2B and B2C sites).

On the plus side, branching prior to new development sped up the work, since the developers did not have to worry about making the new code compatible with the existing code. Isolating the European changes made SQ testing easier and quicker. On the minus side it signaled a departure from a well-established practice: Develop in trunk, then branch with a stable release candidate. When branches receive only bug fixes these can easily be integrated simultaneously into the trunk, but it's hard to find the time to bring new development from the branch to the trunk—especially when working under a tight deadline.

This past week the hundreds of code changes that were developed in the branch were merged into the trunk. The main developer on the project, "René" just threw the code over the wall. That is, he dumped the new work into the trunk without even bothering to test it in the two other sites that have been continuously developing in the trunk since the branch began, and it broke every area of the site it affected.
 
When the UI broke from his sloppy merges René circulated a series of harsh emails denouncing the CSS for not being adequately flexible and bulletproof, criticizing the UI developers for not making it so, and mandating that they "fix it". I fought back by sending screen captures of the page with outlining turned on (WebDeveloper Toolbar) so everyone could see how badly he had screwed up the HTML structure. So now we have a full-blown war on our hands. David refuses to speak to René because he resents being publicly blamed for the developers' mistakes. René isn't speaking to me because he knows I blame him for the mess and can offer a considerable amount of proof to support that position, and because he's been "working from home" a lot recently.

The amazing thing, to me, is that the managers associated with that project and with the other two sites came to my cubicle yesterday to me ask me why I think the merging of the branch code is screwing up the trunk code so badly. Since they hadn't been paying attention at the beginning of the project when we discussed what the effect of this project would be on our "unified code", I recapped for them how the Europeans' redesign project violated best practices on just about every level possible, how the incompatibility of their changes with our existing functionality resulted in dangerously complex, badly structured code, and how the complete lack of documentation insured that we would never be able to either fully understand or support these changes. They agreed with my comments, but they also seemed mystified something like that could actually happen. I reminded them that, as an organization, we have no professional standards and a spineless executive team, and went back to work.

The unfortunate thing is that I don't believe our IT department will learn from this debacle. If we discuss the failing of this project at all, we'll allocate the least amount of blame possible. And we'll place it on those least able to defend themselves. In other words, there will be some restrained comments about the failings of the European team and we'll hold a series of meetings to discuss re-architecting the CSS.

Oh, and by the way, we're currently meeting to discuss the Europeans' new design of the product detail page—the most crucial and the most structurally complex page of the site. We're working from the graphical mockup the Europeans provided. They've built the interface around two interactive catalog features we are not currently able to implement and which we have no plans to implement in the near future. And they left the most valuable piece of real estate on the page blank. Their layout will break in Italy and it doesn't work for countries that must show prices both with and without tax, nor does it accommodate the alternative layout required by customizable products. Here we go again…

The new design we did for the Europeans just launched. It took three times longer than it was supposed to, which deserves some discussion. First, poor David only had one week to do all that work. It wasn't possible, so they gave him another week then another. It took longer than anticipated because (as is the "agile way") we develop as we go and that means we have a shifting target. Also, there was the inevitable scope creep. All of the things that weren't figured out in the design stage had to be figured out in the development stage, which is a lot more expensive. Oh, and those design comps the Europeans cut and pasted together that they said were just to give us a rough idea of what they wanted? Turns out they wanted it to look exactly like the comps.

As predicted, the new design caused massive forking in the "unified code". Some pages were so different than our standard version that new pages had to be created. Other pages stayed as single pages, but they were double the size, as every content area was included twice so it could appear in different places for the different version of the site we now had. This will be a nightmare to maintain going forward. Thank God for proper documentation! (Oops! Guess there wasn't time for that.)

As was also predicted the interface broke in many places. Although I insisted that Europe provide versions of their mockups that showed the languages that are prone to problems, particularly Italian and German (Italian phrases tend to be a bit verbose; German words can be quite long without a place to break) they refused to make the effort. I made of mockup myself of how their page would break in Italian. It was ignored. Funny enough, it is a perfect likeness of the screen capture David has in one of his new Jiras.

The earlier version of the site took into account all the various international use cases and the variations caused by the languages. The new version only treated the UK. But now that the interface is breaking everywhere but in English no one is blaming the Europeans for failing to create a design that aligns with the needs of all of their component countries. Everyone is trying to blame the CSS. CSS, aparently, is supposed to magically work across all languages and all browsers all the time regardless of how much you change the content that it is styling.

But what truly perplexes me is the fallout. All the problems I predicted would occur did. The site looks as bad or worse than I said it would. The information architecture and usability is so laughably bad that when the lead designer for our group and I went through it together we were speechless. All we could do was laugh. So why is everyone acting surprised at this mess they created? Executives thought they were qualified to do web design, didn't listen to those who were qualified, and produced a train wreck. And they're surprised by this. The head of our team told me, "It's okay if we don't have sufficient documentation for this project. We'll design as we develop." Now we have an excellent example of why that isn't a smart idea.

There's a meeting coming up to discuss how we can fix this mess. The focus, according to what I've heard so far, is to make changes to the CSS and the interface so that no matter what we do the interface will never break. Good luck with that plan. And we'll also be discussing how this happened in the first place. That will also be a waste of time. They didn't want to hear it at the beginning as a warning and they'll want to hear it even less at the end as an "I told you so."

I think I'll skip that meeting. I'm still "agreeing to disagree." Until our executive teams develops enough backbone to say "NO" we're going to keep wasting time, money and energy that we could be using to increase or bottom line. We're going to produce one disaster after another, then spend more time trying to clean them up. Wake up, guys. CSS isn't the problem here.

 

"Never attribute to malice that which can be adequately explained by stupidity."

"We can do this by trial and error. We're in a hurry so we'll have to design as we code—be agile... And if you run into a problem, just look around at our competitors' websites and see how they're handling it." — the department head, Global E-Commerce

I said, "The Europeans strongly believe that they understand what their customers want. They believe equally strongly that we don't—that what works for us won't work for them."
"...which is what makes their sales figures so ironic," added J.

The book Head First Design Patterns defines a design pattern with this simple statement: "A pattern is a solution to a problem in a context." The usability study that kicked off the redesign project framed the site's problems in design patterns like "Understanding", "Organization", and "Recognizability". After identifying a problem the test user encountered, they would match it to an established pattern, then use that pattern's guidelines to suggest a solution for the particular application. In this case, the user's difficulty completing a task defined the problem and the activity during which this surfaced was the context.

It occurred to me that if the problem or the context was not so clearly defined or delineated it would be possible to get one or both of these wrong. If you did, your solution would be wrong as well. Looking at the other half of the equation, you could also choose the wrong pattern for your solution. In usability we work from a list of clearly defined and well-tested patterns. In life we work from patterns that aren't as clearly codified. Sometimes these patterns are management principles and sometimes they are de facto patterns created by repeating an action or decision until it feels familiar.

What if some of these de facto patterns were actually inverse patterns or anti-patterns? That is, instead of being solutions they were recipes for disaster? If that were the case maybe disaster could be avoided. Perhaps it depends on correctly identifying all three pieces of the pattern equation. That is, clearly and correctly understanding the problem and the context, then applying a proven pattern.

If two groups of hikers are lost in the woods and one group decides to hunker down and wait for a rescue and the other decides to look for a path out of the woods, which group will have the best chance of survival? They both have the same problem: they are lost in the woods. Here's where the context is important because it helps define the problem. For instance, "We're lost in the woods with plenty of food but no shelter and there's a snowstorm coming over that mountain" is a different context from "We have tents and sleeping bags, but no food and we're at least a day's walk from the park entrance." In the first context the best decision might be to find shelter and wait it out. In the second context you can protect yourself on the journey, but you don't have enough food to risk being snowed in for a week.

In the specific case of our redesign project the Europeans' problem was "How can we quickly stop the downward trend of our online sales?" Their context was a website we'd built for them that they didn't believe fit the needs of their European market. Their solution was to redesign the checkout process as quickly as possible, without further input from us, and push it through in time for the earliest release possible. From our side the context was "When the Europeans give us a development project the funds they allocate to our department improve our bottom line and make the managers look good. So our problem was "How can we employ our team to give the European's what they're asking for?" The solution to that problem was "Find a way to implement their design proposal." Seen that way it all makes sense. Both sides are effectively solving their problems. It should be a win-win situation. So why does it smell so bad?

The answer to that question, I think, is in the solutions. To distill both of the above solutions to their simplest and harshest terms, they look like this. For the Europeans the solution becomes "Throw together a new checkout process in two days and launch it with no user acceptance testing and hope it works." For us it is "Develop a web application interface using a rough graphical sketch as our sole architectural document and hope it works."

I'm still on the meeting roster. Gee… If David is going to be implementing this he really ought to be invited to the meetings at some point…

This meeting is about feasibility. Forget for a moment that we don't have a working design. Our site flow diagram wasn't made in Visio—it's just snaps of the cut-and-paste comps with arrows going between them. We don't have wireframes and the comps are still just "rough drafts", so we're not exactly sure what the pages are going to look like or what they're going to do. The term "ajax" has been bandied about, but no one is quite sure what that involves. We'll sort that out later. For now we're just asking in a conceptual way if "this" can be done.

What is "this"? It's a generalized flow. Can we make this sort of server call? Can we send a user here instead of there? The back-end guys have a few concerns, but in principle there is nothing that can't be done. We don't need to concern ourselves about technical architecture or how convoluted flows might affect our code base. We don't have a TA and we never will. Theoretically, it's all good.

I found myself thinking about war crimes. Tribunals convene and, outraged, they ask, "How could this have happened? When did you let go of all decency and commit this hideous crime?" The answer is an ashamed admission that it happened gradually. One small thing led to another small thing. There was no plan to do what happened. It just… happened.

"Venkat" said the server could be made to do it that way. "Matt" said he'd seen cases where that sort of call could be made to the database. We were talking "technical" so interface didn't matter. IA didn't matter—not at this stage. We were just talking feasibility. Is it feasible? Yes.

But now that the back end guys have let it pass without a red flag it has firmly ensconced itself in the realm of the possible. It is now viable, i.e. It's alive!

When I came in on Monday morning I had a 10 am meeting with Randy, Edmund and Erica. I thought it was going to be brief account of how the Europeans took the news that we weren't going to be using their half-baked comps as a basis for global e-commerce web development. Imagine my surprise when Edmund and Randy began the meeting with a discussion of scheduling for the project.

Did I fall into a parallel universe? What had happened to "no"? Instead I heard comments like, "There nothing here that we couldn't do" and  "It just needs a little tweaking." Edmund diagrammed the new flow on the white board and to me it looked like a ball of yarn, but Randy said, "I'll diagram that in Visio and get it out to them by the end of the day."

I reminded Edmund that architecture is an integrated framework. It all has to work together and if one part of it is flawed it affects the entire design. Everything has to make sense before you begin or you risk going down a dead end.

I also pointed out that it was lunacy to think that in 2008 web development could be done by executives who had no knowledge of usability or information architecture. His answer was, "We'll just have to agree to disagree." (Since he's my boss's boss that translates to "Shut up.") A few minutes later when Randy asked him if he thought we could make this thing work he said, "I've been in e-commerce for ten years—I feel comfortable designing the new site for them."

I took one last shot. "What are we going to do about resources? Am I still full time on our B2B site?"

"Yes," he replied. "We'll get "David" to handle this."

David was hired three weeks ago. He's number two in our global e-commerce presentation layer development group...of two. So now I'm just a bystander. I was that annoying character in the movie who kept saying stuff like, "If we stay here we'll die! We have to get to that town we flew over and get help!" and who finally abandons the group to find salvation on his own instead of waiting for rescue. Anyway, maybe I'm being too dramatic, but I think there's a good chance I won't get eaten—at least not in the first round. But just in case, I added up all my time off. I might need an escape route.

I met with Randy, Edmund and "Erica" (the business analyst for Europe). We all agreed that it was a no-go situation. We couldn't possibly begin development based on what they sent us. It was agreed by all that we'd have to say "no". Edmund asked my opinion about the whole situation and I was flattered, because usually he just talks and isn't big on listening.

I told him I thought the problem was that Europe was, essentially, a small pond. Even though they make only a fraction of the revenue we do they have short chains of command and they're headed by a V.P.-level executive. If one of their regional managers doesn't like what we're doing they push back, but they go directly to their V.P. and he pushes back on us at our director level and rams it down the chain of command in our IT department. So they effectively own the global web dev. team. For us to trump them we have to climb very, very high up our chain of command to find a V.P. of equal status and power, and those guys don't concern themselves with such low-level issues.

Edmund agreed saying, "If I have to call my V.P. it means that I've failed to do my job." He thanked me for my insight and assured me that this time it was going to be different. We had to say "no" and we would say "no". He asked me to prepare a brief PowerPoint outlining the reasons we couldn't go ahead with the European proposal (for ammunition), which I submitted that Friday morning. I went home at the end of the day thinking that it was all going to be okay after all. My bosses were finally going to push back, we wouldn't trash our code trying to rebuild the site for the Europeans and we'd find a way to roll their usability update into the one we were planning for Q1 of next year. What a relief!