All About Design Thinking, All of the Time

Compared to many major online publishers Edmunds is small in terms of employee count. We're about 400 strong.

One of the many advantages of being small is that when the time comes, we can turn on a dime. And we have. We're moving in a new direction in which Design Thinking is becoming core to the way we do business.

Over the last 6 months we've been all about Design Thinking, all of the time! We've established a group of researchers that go out into the field to find out as much as we can about the people that use Edmunds.com and how they use Edmunds.com.

We're reaching out and we're reaching in. The company has organized Challenge Teams. Each team has a particular focus on improving how Edmunds experience for its users, both external and internal. Now, before we put our nose to the grindstone to make something, we talk to the user first. It's becoming more common to go past a conference room and see a group of Edmunds employees in a video conference call with an end user on the other end of the conversation. Or, if we're developing an internal tool, the development team will run a paper prototype past the internal group requesting the work.

The month of January has been an exciting month. All the employees went through formal training sessions to learn the particulars of Design Thinking. Also, all of the Edmunds Challenges Teams had to walk the talk. We ran a month long exercise in which each Challenge Team had to use the Design Thinking process to create a product or service.

The culmination of these creative efforts was a company wide Design Thinking Trade Show. Each Challenge Team presented its product/service in our company's common room following a trade show format. (We call the common room, The Great Room.)

Each Challenge Team set up a booth. Employee walked from booth to booth to get sold on the Challenge Teams idea. And, as an added kicker, each both had a "vote sheet" upon which a wandering employee graded the booth, as Best Booth, Second Best, Third Best. At the end of the Trade Show a winner was determined by a tally of the votes given.

We shot video and photos of the event. Below we've posted the photos of some of the Challenge Teams at their booths with a brief description of the idea they developed. Enjoy!

Not to git

Back in October, I wrote a post "To Git or Not To Git." At the time, one of our teams started to work with distributed revision control (drcs). The team looked at both Git and Mercurial. At the end of the day they decided to test using drcs with Mercurial. I tried to stay out of the decision as, on the face of it, both systems offer the same basic feature set. After a few months we took a look at our usage to decide if we should move forward or not.

First a little background, we chose to test the use of drcs with a brand new project to ensure we did not have to worry about existing source structures in perforce. The new project is the rewrite of our data warehouse ETL system using Hadoop. The code part of the project breaks down into data loaders, data transform workflows, and data exporters for each subject area (ads, clickstream, etc.) as well as common components shared across subject areas. The configuration part breaks down into puppet configurations and mcollective deployment agents for pushing our code. For the beginning of the project we focused on a single subject area. Besides keeping the test project limited in scope, we wanted to ensure we could fail easily. The ability for both git and mercurial to sync back to perforce meant that regardless of the outcome we had a fall back scenario that ensured we could fail without too much consequence.

We liked a number of things we found when using drcs; performance was great, developers could commit code from home or elsewhere without network access, developers could make changes safely and easily isolate their changes from others. We liked the ability to have a robust model for creating authoritative repositories and the ease at which we could merge feature type branches. In short drcs had a lot going for it.

However, there were a number of things we did not like. The ability to commit changes offline is nice, however, unless you push the changes to a central server for others to see your commit is, in a sense, incomplete. Watching our central hg server, I do not see a lot of people pushing changes up on a regular basis. Knowing that people are not pushing up makes me wonder if they are pulling on a regular basis. Granted, not pulling, or syncing, is an issue with any rcs, however drcs adds the further requirement to not only commit but push your commits up. It also gives you the ability to choose where you pull changes from. If you don't have to push and can pull from anywhere how do you maintain a sane stable continuous integration environment?

As we move our organization towards continuous delivery the fact that there are numerous branches of code and an unknown integration state seems to be problematic. I would rather have everyone checking into a common trunk with no branches to ensure we are always in an integrated state. While the drcs tools provide great merge tools, textual merges do not always result in semantically correct code. Fundamentally, I do not think that having feature branches allows us to get to the continuous delivery model we are pushing towards (flame here ;-).

Additionally, in order to have clean push, pull, branch semantics one does not want to have a single monolithic repository. The question then becomes what is the appropriate granularity for a repository? We decided that a repository granularity was dependent on a deployable unit of code. However, this lead us to have seven repositories for our small project. With repository explosion I wonder how a new developer to the team would even know where to start. There are additions to both hg and git to allow rudimentary project grouping, however, compared to our perforce implementation we would not be able to create the nice logical source tree we have now.

I do not believe any of the above issues are insurmountable, however, given the issues, we became uncertain if the cost was worth the benefits. For now, we are staying on perforce. However, given the power of the git and hg integration with p4 we have a number of developers that are sticking with the tools that work best for them. At the end of the day developer productivity is what is more important to me and it seems, as far as scm is concerned, we are in a good place.

Google Tech Talk: How Edmunds Got in The Fast Lane

Last week, I had the pleasure to speak to a room full of smart people about the exciting practices we have employed here at Edmunds to make our pages faster. I wrote about these practices earlier and co-authored a blog post on the Google Code blog about it as well.

Here's the deck I presented:

The 5 Rules of 3rd-Party Widget Development

As web developers, we incessantly complain about other people's code that we embed (out of necessity sometimes) on our pages.  Most of the time, our complaints are justified since the vast majority of 3rd-party providers develop their widgets and code in a way that negatively impacts the performance and functional integrity of the host page.

Now that we're embarking on becoming 3rd-party providers ourselves, we want to make sure we avoid all the traps that others have fallen into and that we've complained about endlessly.  Here is a list of the 5 rules that I think could make 3rd-party code a pleasure to work with:

1. USE STANDARD WEB TECHNOLOGY: Completely avoid plugins, including Flash, when building out widgets. Almost everything you can do in Flash is doable using HTML 5.
   
   


2. DO NOT IMPACT PERFORMANCE: One of the main complaints we developers have about most 3rd-party widgets is that they invariably bring our page performance down.  With page performance being part of the overall credibility of sites these days, it's very important that the widgets you create are not impacting performance at all.  This is done by:




1. Using non-blocking methods to download resources


2. Making as little HTTP requests as possible


3. Executing code when needed


4. Cache resources that don't change often
   
   




3. DO NOT USE document.write(): If you do not want to piss off the developer that is working with your code, don't use document.write().  The problem with document.write() is that it needs to be executed before the page is done loading, which doesn't give the developer much choice of when and how to include the widget.  Avoid it at all cost!


4. DO NOT DEPEND ON DOM EVENTS: Depending on onLoad or onDOMReady or any other time event on the page is a bad idea.  You're forcing the developer to add your widget before these events are fired, which might impact the performance of the page he or she is developing. 
   
   


5. PROVIDE AN API FOR YOUR WIDGET: The power of the Application Programming Interface (API) is that it gives the end developer control of when, where and how to incorporate your widget on his/her page.  The goal here is to be as unobtrusive as possible and with an API you can make that happen.  Developers will love you for it!

What do you guys think?  Does this make sense?  Did I miss anything?  It would be great to develop a test through which every 3rd-party widget goes to make sure it plays well with other components on a page.

Looking forward to your feedback.

Software Development by Any Other Name

I figured out something. I figured out how to learn everything that you need to know about the best practices in software development in 3 days. It's called the Edmunds All Company Meeting.

Allow me to elaborate.

The Edmunds All Company Meeting is the semiannual gathering of all 400+ Edmunds employees. We gather together in the Summer and in the Winter to get the latest information from the CEO, COO and President about the past performance, present state and future direction of the Company.

The 2010 Summer and Winter Meetings, of which I was the producer, were held at the Broad Stage nearby in Santa Monica. The Broad Stage is a very professional venue capable of hosting anything from a traveling Broadway production to any corporate event.

The Meeting is a big deal...a big expensive deal that involves the efforts of many people. We had designers working with the executives creating the Keynote presentations. We commissioned a production company to make a complex graphical video, the Edmunds Way. (The video outlines the future philosophy and direction of the company.) We added extra musicians to support the employee-musicians of the Edmunds Orchestra that plays throughout the meeting. Edmunds employees served as stage hands and production staff.

All members of the meeting, production staff and executives, spent weeks in preparation for the event. The culmination of the preparation was a night spent in the studio in Orchestra Rehearsal and a full day spent in the theater in what we call, "Dress Rehearsal", and then the Day of the Meeting. For all intents and purposes, the All Company Meeting is a fully fledged theatrical production. In terms of a full staffed production, we had 3 days to prepare and perform.

So you may ask, what does any of this have to do with software development?

Software development and theatrical production have a lot of things in common. You get an idea in your head about an experience that you want to create. You spend time, money and lots of people-hours working to make the idea real. Then, after all the money is spent and the preparation work is done, you put what you've done in front of an audience. If the audience likes what you've done, you continue, it not..... well, the show closes.

It's all about curtain time/ship date. All the time invested, money spent, hours worked does not mean squat if the show does not go on. In fact, if the show does not go on, if the software does not ship, the entire effort is one big, expensive waste.

So again, what does all this have to do with software development?

Effective software development teams tend to look like high functioning theatrical productions. The term "they've been bitten by the bug" is applicable to both groups. Individual motivation is high. All participants have a clear, common idea of the production process, what the final product looks like and all understand each individual's role in the production overall. Most times awareness of the production is so pronounced that members can function in many roles and can "fill in" for others should the need arise.

Mitigating Risk: Understudies and Backup

On the practical end, mitigating risk is a continuous undertaking in both environments. Producers/managers are always asking, "What happens if Joe or Jane gets hit by a bus?" In the theater the major roles have understudies. In a well run software development team technological expertise is distributed. No one head holds mission critical knowledge.

No production is ever comprised because an important piece of equipment malfunctions. Nobody goes on stage at a Rolling Stones concert and says "Mick can't sing tonight because we blew the amps!" The Edmunds site does not go down because we lose a server. Just as there is always a back up amplifier, we have backup for all of our hardware dependencies.

For me the most telling aspect that a theatrical production is software development by any other name is the paramount importance of reliability-- that the investors and audience can rely upon the crew and cast to ensure that the show will go on...no matter what.

reliability = (showing up on time) + (being ready and able to do what is expected of you) + (letting others know what's going on with you)

Allow me to elaborate some more.

(showing up on time)
Keeping an entire production crew, theatrical or software, waiting for you to show up to do your job wastes time and costs money. Professionals show up on time, if not early.

(being ready and able to do what is expected of you)
Drunk talent in a dressing room sucks. A developer zoned out playing Mafia Wars sucks. 'nuff said.

(letting others know what's going on with you)
Leaving the theater during rehearsal to go to the bathroom without telling anybody that you are leaving means that the production crew gets to play, "Where's Jerry? He was here a minute ago. We need some lights adjusted."
 
Going offline during a critical deployment means the development team gets to play, "Where's Mary? Her code is not building. We need to tell her to make a change. It looks like she's on Instant Messaging. But she's not responding."

Neither of these games are fun.

Software Development by Any Other Name

It's been my long held belief that if you can be a reliable member of a theatrical production, no matter the role, large production or small, professional or amateur, there is a good chance that you'll make an excellent member of a software development team. Yeah, you have to know code and code related stuff to do software. But the core desired behaviors exist in both environments:

• being willing to contribute to a common vision


• showing up on time, being able to perform as expected


• being able to take and give direction


• not disappearing unexpectedly


• making a commitment that no matter what, the show must go on.

So as I learned in my 3 days producing the Edmunds All Company Meeting, "The show that does not go on, isn't" and "software that does not ship, ain't".