Game Optimization: A Farmville Sheep (Case) Study

A sheep stands in his field. Munching. Baa-ing. Wait, is that—spaghetti on his head? A bib around his neck? Aww, that’s the cutest sheep I ever did see! But why is that darn sucker moving so slow?

In fact, our poor wooly friend is an animation from Zynga’s game FarmVille. When we worked on this game, 140 million of you were coming back daily to plant and sow. Well, not YOU, of course! But if no one admits to it, where did all those players come from?

When optimizing art assets for Zynga’s Farmville, we noticed that some graphics had huge performance problems. In fact, some of players’ most favorite animals on the farm slowed game play to a crawl. And since Zynga depends on solid game performance to retain its user base, this was serious business.

Our first instinct was to build an art optimizer to simplify the artwork and make it faster via a process called rasterization. And it worked! Great, done—that’s all folks, the end.

BUT we all wanted to know more—why were some artists better than others at making cute little animals that would also show up on your screen with lightning speed? 

There were plenty of other sheep on the farm that looked great and didn’t slow game play, so why was our spaghetti guy causing all sorts of trouble? It turns out it wasn’t the sheep—it was the spaghetti.

Get out of the building moment

Suddenly, the problem the spaghetti bowl caused made so much sense—the artist had individually drawn each noodle in glorious pasta-riffic detail.

Displayed up close on a large-screen monitor, all that detail looked great. But in the game, the entire bowl of spaghetti was just a few pixels across, so the detail was superfluous.

Our optimizer tool allows us to easily spot animation performance problems and improve them.

At that moment, it occurred to us that the problem here wasn’t optimization, it was training.

I immediately scheduled a meeting with the FarmVille studio art director and a few of the artists on the team. They were really surprised at the impact a few extra pen strokes had on game performance.

To find performance bottlenecks in other artwork, we next built the Zynga Analyzer, a tool that integrated directly with the artist’s workflow. With each action in the authoring environment, an artist could see the impact on performance.   

The Analyzer tool helped give everyone a sense of how much drawing “budget” they had for a given character. Some drawing techniques, such as transparency and shading, had more impact on performance than others.

Everyone wanted to install it to find out what they were doing right and which art assets could be improved. Given these constraints, I saw that Zynga artists were incredibly clever at making cute illustrations that also performed well.

The Zynga Analyzer depicts how the artist has consumed their asset “budget.”

What started as an engineering optimization problem had morphed into an artist training program. The tool that exposed total impact on game performance now instilled a bit of self-reinforcing competition within the art team. Artists were spurred on to create illustrations that looked great and performed well. By exposing character performance during the creation process artists felt they had skin in the game, so to speak.

And finally, for illustrations with no fat to cut, the Optimizer tool gave an animation a bit more pep in its step. Altogether the effort once again secured each special animal’s place on the farm, including our little sheep who can now munch spaghetti till the cows come home.

Questions to ask when developing a retail mobile strategy

Lately, retailers (both large and small) have seemed to focus on their omni-channel strategy: leveraging social channels to drive traffic, traditional mediums to promote cross-channel awareness, and e-commerce to streamline the transaction process.

But what about the mobile touch point of the customer experience? These days, many retailers have a mobile app: but is this the right mobile app for you and your customer? In an age where nearly 58% of customers conduct online/social research prior to purchasing an item at a brick-and-mortar retail store, retailers should be thinking about how their app can (a) enhance the customer experience and (b) streamline the path to purchase. Sometimes these objectives are one in the same. Here are some questions to ask yourself when developing a mobile strategy for your retail environment.

What are your customer’s pain points? Every retailer is different: Different store layouts, different SKUs, different check-out process. As a retailer, you should ask your customers what their biggest pain points are when shopping in your brick-and-mortar retail store. By the same token, you should also ask yourself how you can solve this pain point with the customer’s mobile device. Some scenarios to think about:

  • Are your checkout lines too long?
  • Do they want to know what is on sale?
  • Do your customers need help with an item?
  • Do your customers need help navigating your store to find a category or SKU?
  • Would your customers prefer a ship-to-home option rather than hauling the item in their car?
  • Do your customers want to know what the price is of an item?

Why should your customer use your app? Once you’ve figured out your customer’s pain points, you should ask yourself why a customer should (a) download and (b) use your app. With thousands of apps on the market, and room for ~20 apps on the user’s Home screen, a better question may be: Why will the customer want to use your app more than once?

  • Do your app solve the problem (above) in a way that enhances the customer experience?
  • Do customers who use your app have a significant advantage over customers who don’t use it?
  • Does the customer receive value in the form of discounts or loyalty rewards?
  • Does the app enhance the offline and cross-channel customer experience?

Operationalizing the mobile experience to wow your customers

In some, or maybe all, of these scenarios the retailer may need to operationalize the experience around the mobile app. For example:

  • How do you handle loss prevention if you implement mobile check-out?
  • How do you greet loyal customers who enter your store?
  • How do you redeem loyalty rewards via the mobile app for a customer who is ready to check-out?
  • Do you offer flash-sales for customers who scan a SKU using their mobile phone, based on their purchasing history?

We believe the best mobile experiences are the ones that “start with the end” — and in the case of retail, we believe starting with the desired customer experience in the context of mobile, will help bring brick-and-mortar retailing to the 21st century.

The Internet of Things: The Connected World Is Here and Now

Look around you and you will see thousands of “things” all within your immediate vicinity. Your keychain. Your desk chair. Your favorite coffee mug filled with Italian Roast coffee. Your dying ficus plant. With today’s technology, there is no reason why these things cannot communicate with you, in-real time.

  • Your plant should tell you, not only that it needs water, but how much and what position to place it during the day
  • Your coffee mug should know what kind of roast you want to drink today
  • You should be able to find your keys at a moment’s notice because you have a bad habit of misplacing them the moment you are about to go somewhere
  • Your desk chair should automatically adjust itself when it detects you are sitting with poor posture (reminder: stop slouching)

As luck would have it, there are technologies for each one of these things, being built. Right. Now. (See for yourself: Plant | Coffee | Keys | Chair).

The Hardware (R)evolution.

While  cliche, the world we are living in is becoming increasingly more connected, more now than ever before. While in research in development only a few years ago, technologies like RFID, NFC, and Zigbee are enabling the next generation of connected devices in a cost and energy efficient way. In fact, consumer goods that weren’t previously connected 18 months ago are now online. Recent examples, include:

As enabling technologies become cheaper and smaller, companies will be forced to innovate and think about how their offline products can get online.


Getting offline products into the 21st century is only the tip of the iceberg. Enhancing these products with connected technologies has to transform the product experience, be personal, and have utility. The bar for product experiences is so high, not executing against these objectives will result in a gimmicky, failure of an experience.

For example: A shoe company may want to create a running shoe with a GPS Dot. These “online shoes” should not only track where (and how long) the user was running, but it should provide actionable insights based on what the shoe company already knows about you: recommend running trails based on your running style and preferences, alert you when your friends are close by, give you a discount if you walk by a their store, and let you know how hard to run based on your body fat and weight goals.

Utility vs. Privacy

Privacy generally is a topic of concern when more devices become online and “all knowing.” As we’ve seen from the internet and media today, and in light of recent NSA privacy concerns, users are willing to give up certain liberties to connect with friends (Facebook), share their thoughts (Twitter), utilize free email (Google), or make free international calls over the internet (Microsoft/Skype). We believe its important for companies who are contemplating an online product strategy understand these implications and balance the utility an online product with the user’s privacy and the company’s ethics/values.

Why Mobile Apps Fail

Apps are Pets

When beginning a mobile, web or other app software project, keep in mind it’s more like adopting a pet than building a product. Software needs continual care, maintenance and feature development. Users expect updates — whether to take advantage of the latest mobile Operating System release, to fix a bug that somehow slipped through Quality Assurance, or simply to add features. Building an app is not a “one-time and you’re done” operation.

Product / Market Fit

Consult the experts, whether  Marc Andressen (co-creator of the first web browser), Steve Blank of Stanford, Paul Graham of Y-Combinator or Sean Ellis of LogMeIn, they all agree: it’s about getting the right product, to the right people. That said, your app’s features should depend heavily on who that app is marketed to. To achieve this takes a lot of  “get out of the building” type thinking promoted by Eric Ries in his book The Lean Startup.  Interacting with your market as soon as possible is paramount.

Agile software development process, user-centric design, and Lean thinking can all help you discover what features to build, but all the theory in the world won’t help unless you learn from your market, measure feedback, and build the features that users desire: you must go through this “build, measure, learn” cycle a few times to get it right.

Build, Measure, Learn: How to achieve product market fit by iteratively achieving small milestones
The Build, Measure, Learn Cycle

Accrue Technical Debt Wisely

You may be initially wowed by a software team that can deliver features fast and furiously — especially when you they look cool, and progress comes swiftly — but in just a few short months, a mobile app project can grind to a halt. Why? At the beginning of a project software developers often build features without building the surrounding infrastructure to support them. It’s like building a glorious bathroom complete with steam shower in a house with no plumbing.

The industry term for this is “technical debt.”  While this form of indebtedness can get you a quick jolt of progress, it can also come back to bite you. For quick experiments, technical debt may be the right option, but for meaningful, high-quality app development, building it right means a robust software architecture, infrastructure to support scaling to a massive audience, and putting in place the security necessary to protect both your users and your investment.

Beware Schedule

There is a reason that, on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. In a survey of 600 people closely related to a software project, 78% of respondents reported that the “Business is usually or always out of sync with project requirements.” It is extremely difficult to correctly estimate large software projects. So, smart teams have stopped trying.

But, without an estimate, how will your app hit deadlines and a budget? The secret is once again, in the agile process: you can correctly estimate software deliverables over the short term. The agile software development process promotes short “sprints” and we suggest a one-week time period.  This way, your team releases a fully-functional and complete product every week! And since you are learning from your users, what you will do over the next few months, will be in direct response to their usage and feedback. Think of a product initiative as an experiment, where the goal is to learn what a market wants, and deliver it.

Beware Users

Asking your users directly what they want (or don’t want) is a pitfall to avoid.  You are the innovator, and you understand the possibilities for future directions of your product better than anyone, including your users, so asking them is asking for trouble. Instead, simply observe them. Focus groups are notorious not only for their expense, but also their “false sense of science.” Studying users behind a one-way mirror may have worked well in that Mad Men episode, but for software, the “Starbucks Method” is about a million times cheaper, and much more insightful. Get into the cafe, hand out some 20’s, 0r buy people lunch in exchange for watching them use your product.

There is no harm in providing a few in-app survey questions.  Take a look at Qualaroo for how to do this well. For building community, GetSatisfaction is a good bet. Bottom line: Target your questions to the specific user experience, not the overall product.

Beware Apple

As the recent “Downpocalypse” of the Apple Developer Center demonstrated (no new iPhone apps could be created for over a week!) hitching your app to a single horse is a dangerous move. Though an initial iOS app release makes sense in many cases, building with cross-platform mobile technologies like HTML5Adobe PhonegapLudei or Unity, allows your app to diversify its bets; placing expensive native features only where they’re needed.  This way you can release on iOS, Android, the Web, even PC, Mac and gaming consoles.

Choose the Right Team

Select a development team that will maximize your budget and give the best value.  Sometimes the cheapest guy on Craig’s List, Upwork, or RentACoder is the right way to go — such as with one-off experiments or when a quick and dirty initial draft of an app on a shoestring budget is expected to be tossed and re-written from scratch — but for most projects, it makes sense to proceed with a team that can provide end-to-end services, engage with your users, and help guide you strategically to that nirvana of mass adoption.

5 Industries that Need More Mobile Apps

Over 120 million Americans now have smartphones.  That’s over 40% of the US population.  And almost every one of them is aware that email, Facebook and Gumulon (and the other fun games of the moment) are what they can do. But when you consider that today’s smartphones have more compute power than all of NASA used to send astronauts to the moon, and  capabilities that can sense: location, proximity, acceleration, compass heading, plus two high-resolution cameras, it’s time to start thinking of these devices in new ways that can benefit a wide range of industries. Here are 5 industries we think stand to benefit from these amazing devices, and applications they might employ.

Home Furnishings

Augmented reality is a fancy way of saying that you display a computer generated image over live video from the camera.  When shopping for home furniture, whether at Ikea, Crate and Barrel or wondering how that Eames Lounger will look in your living room, a mobile app can show you what your furniture will look like in your home or office. The amazing 3d graphics of Hollywood movies are now available in handheld form-just imagine seeing how new carpet, flooring, cabinets, appliances, or art will look in this spot—no over there a bit to the left.  Think this is just something of the future?  Check out these augmented reality apps and see for yourself.


You already use your mobile phone with OpenTable, Yelp, Urban Spoon, or maybe just Google Maps, but there’s more to come from the mobile world that will transform not just the restaurant discovery experience, but dining itself, not to mention restaurant ownership and operations.
Soon you will review nearby listings, and be greeted by a local restaurant’s maitre d’.  The special tonight is a fresh seared Ahi, and the chef has a table near the window, which we think you’d enjoy.  Come on down and we’ll send you a free glass of wine and an appetizer.  Oh and by the way, those peanut allergies will not be a problem with any of the items we recommend for you.
A restaurant owner will soon be able to take a snapshot of their menu, and OCR software will instantly update their mobile site, so users walking by can know exactly what’s hot (literally) at this spot.


From electronic health records (EHR) to checking for drug interactions, to refilling prescriptions, both doctors and patients already tote mobile apps in their arsenal, but prepare for future shock when remote diagnosis, doctor-patient video chat, social network support groups, and even health equipment monitoring connects to smart phones and tablets. This is all made possible by recent software technology advances for HIPAA-compliance to protect patient privacy, and digital communication standards such as Health Level 7 (HL7) that allow a wide range of medical devices to talk with each other and external devices.

Industrial Control Systems

Industrial Process Control is a set of devices and software tools that allow factory managers to monitor and control the operation of manufacturin or industrial production equipment.  A new generation of wireless sensor technology, called Zigbee, allows industries to create mesh networks of sensors, so the next time that pressure gauge is reading a bit too high, or a silo level is a bit too low, you’re notified, instantly in your pocket or on your tablet.

Customer Support

Making that phone call to customer support is about as fun as making an appointment for a root canal.  Yet, what if the phone call wasn’t a call at all?  Mobile technologies are being deployed by businesses to make customer support communication fast, but the next step is all about eliminating customer support in favor of customer service. Right now, just sending an @reply on Twitter and many top brands will respond very rapidly (with no hold music).  And when companies think of their customers more like the way they think of partners, your connection to the folks who make, manage and distribute consumer products changes your whole product usage experience.   Image credit:

How Social Media Makes Us More Polite

Spam. Viruses. Flame wars. Trolls. Hackers. The internet sure seems like a rough and tumble place. But is it possible that using social media makes us more respectful of each other and more polite? Being polite whether online or off, is strongly influenced by your relationship with person on the other side of the conversation. If there’s no chance of seeing that person in real life, doing business with them in the future, or understanding much about them—there’s a much higher incidence of an impolite interaction: anonymity breeds rudeness.

And the more anonymous, the more rude. So, online forums that allow anonymous posting or little user validation are breeding grounds for bile and the vile (see 4chan… if you dare). Even Reddit, which requires that its users reveal zero personal information, still has a reputation system that

On the contrary social networks that promote authenticity and personal identification. Be yourself, and you have to stand by your rep. LinkedIn, AirBnB, even EBay are great examples, though more private invite-only social networks like A Small World demonstrate the concept as well.

Is it possible that the era when the pushiest jerk gets ahead is coming to a close? Maybe not, but the revenge of the nerds has certainly proven its might, and those who participate in the global conversation with impeccable ethics may just see rewards beyond those knowing smiles.

Concrete Interactive Selected as Early Leap Motion Developer

It’s a privilege for us to be working with the futuristic visionaries over at Leap Motion.  In the coming weeks we’ll report our progress building the first apps that take advantage of their 3D hand tracking control.

Concrete Interactive brings extensive 3D graphics and interaction experience to the world of Leap’s new motion control.  But for a start, we thought we’d remake the classic carnival game and are proud to bring you a little demo of what the Leap is capable of with….Smack-A-Rat.

Smack-A-Rat Game for Leap Motion Controller from Brett Levine on Vimeo.

Code as Content

Modern software practices were brought up on computer science pedagogy that promotes clean and beautiful object-oriented (OO) architectures. They were fed a healthy dose of open source-powered movement toward behavior driven development (BDD). Not quite all grown up yet, these efforts are aimed at producing high quality software outcomes. There is still a missing link in the chain that connects a user’s interaction with a software developer’s intention when it comes to content.

The web is full of content. And the line between content and software is becoming more difficult to detect. While many can make persuasive arguments that coding is an art–“artwork” at least has a different character as “content” and it doesn’t nest so nicely in software architects’ object hierarchies. Content requires different standards from both an OO and BDD point of view.

On one side of the line, for example, no one would rightly call an image file “software”. Similarly no one would call a sorting algorithm “artwork”. A procedural flocking animation written for the HTML 5 canvas though is tricky.

When an artist (call them a creative coder) performs that mystical creative act of bringing a piece of artistic content into the world, more and more these days that act may involve writing code, but the artist may consider that code just a means to an end–expression.

So the point isn’t about drawing a line, so to speak, between software and art. This isn’t a metaphysical discussion. The application of OO and BDD techniques to art are different, and recognizing how to architect and how to test content vs code may mean the difference between expending resources effectively, or squandering them. I’ll save the implications of object-oriented architecture on art for another day, for now I’ll focus on the BDD side.

What would behavior driven development tests of artwork look like? Remember BDD starts with user stories in human terms: what experience do I want the person using my software to have? So for example, a common BDD story would be written like this: “As a Facebook user, when I login, then I should see my news feed.” And a programmer could write software tests that perform just those steps: login to facebook with a valid username and password, check what page appears, is it the user’s news feed? If so, PASS.

If the question turns to, “what experience do I want the person viewing my content to have,” the BDD user story might become, “As a Facebook user, when I scroll my news feed, then I want to feel like it has a physical weightiness.” Yikes, how does a programmer write a software test for this nicely articulated artistic motivation? Weightiness? Well, artist, what do you mean by that?

Effective BDD would require the artistic motivation to be reduced to purely software terms, perhaps: “As a Facebook user, when I scroll my news feed, then its scrolling motion should decelerate gradually when I release my mouse.” This is not a naturally artistic statement. The artist had in mind to make a page that feels weighty, so involving words like deceleration pollutes the user story with the “hows” instead of sticking to the “whats.”

As opposed to artists, for non-programmer product designers, BDD requires expressing in human terms what software should do. But it can only be successful if the language those product designers use to describe the software is actually testable by the engineers who write the tests.

Let’s face it, art is hard to describe, and unless its creator is also a bonafide critic, even artists themselves usually do not possess the language to describe the reaction they wish to engender in their audience. Content is in fact, not software, and should not be tested as software.

Content by its nature, even if it involves software, does not fit a software testing model. Perhaps a new model is needed to provide a softer, squishier, more qualitative way to evaluate whether content is operating effectively.

We can test whether an image renders on the screen correctly. We can test whether an animation with easing is slowing according to a cosine or a cubic curve. But how do we test if a user thinks the Facebook news feed feels weighty?

I think the answer is: ask them. BDD forms part of a software “immune system” but it is only one layer, just as unit testing, and human quality assurance testing are others. With all of today’s emphasis on metrics, it is time for BDD to naturally extend outward, beyond the bounds of the continuous integration servers that execute software tests with each commit, beyond the confines of the software develop’s network, and out into the world, where people can look at a software feature combined with its content, react to it, and tell you what they think–analytically, scientifically, measurably.

I imagine a BDD user story of the future to tie with an analytics system like this, “As a facebook user when I scroll my news feed I should feel as if it were weighty.” And I imagine a test report with a result such as “18% feel the news feed is somewhat weight, 48% feel the news feed is very weight, 4% feel the news feed is too weighty.” Some metrics frameworks such as Qualaroo, or conversion experts such as CROmetrics will provide this sort of data, but to use them, you have to separately set up the metrics system, ask the right questions and compare the results outside the normal design and development cycle.

Software maturity would benefit if the distance between the qualitative usage measurement (in the wild) and the design of software were shortened, in the same way that BDD shortens the distance between usage correctness and software implementation. It is time for customer experience data to integrate seamlessly with BDD toolkits so that artist intentions, no matter how much or little code is involved, align with the business, usage and artistic intentions of software products.

Credits: What Is Art

How Concrete and Zencoder brought high quality video to HitRECord

Thanks to Zencoder and HitRECord for the kind words. Encoding high quality video was a snap with their Ruby on Rails cloud technology.

Reposted from:

With infinite “airtime” and consumer demand going through the roof, a consistent theme in 2011 and now for 2012 is that high quality content is essential for entertaining and engaging viewers. To fill the pipes, big companies are pouring big bucks into producing original content for online distribution. Google is investing $100M in original content for YouTube. We all rejoiced as Netflix resurrected “Arrested Development”, and Yahoo landed a Hollywood whale in Tom Hanks and his animated series.

In recognition of the importance of content in advancing the online video industry, we’re highlighting our partner Concrete Interactive and the amazing product that they’ve built for HitRECord. HitRECord, founded by actor Joseph Gordon-Levitt, not only facilitates the creation of high quality Internet video but is also unique in that it’s democratizing, and bringing real innovation to, the process of content creation.

Founded in 2005, HitRECord has established itself as a unique destination for video artists, filmmakers, writers, animators, musicians, and videographers to collaborate and interact with Gordon-Levitt and others on a wide variety of creative endeavors. HitRECord’s library has grown to over 20,000 complete videos. Almost 1,000 contributors have used HitRECord to create films and video, which are available in the “TheRecord Store”. Thousands more have contributed to films shown at HitRECord’s live shows. When a production makes money, there’s a 50/50 revenue split between HitRECord and the co-creators.

Even though we didn’t get to hobnob with the stars in Park City, we were excited to hear of the successful showcase of HitRECord’s works, which were featured last week at the prestigious Eccles Theater as part of the 2012 Sundance Film Festival. Joseph Gordon-Levitt emceed a sold-out screening, presenting films that were developed on HitRECord.

A few factors are making this explosion of Internet content possible. First, it’s getting cheaper and cheaper to create content. The cost of HD cameras and powerful editing suites have fallen rapidly, making it possible to create professional content on a small budget. On the distribution end, highly efficient software and cloud-based infrastructure make it possible to rapidly deploy Internet video applications with a relatively small upfront investment.

To build HitRECord, Concrete Interactive, the San Francisco-based boutique web application development firm, used technologies such as Rubyon Rails, Heroku, Amazon S3, JQuery, New Relic, Splunk, Airbrake, and Kissmetrics. They use Zencoder, and relied on our industry-leading performance to encode HitRECord’s library. They were able to convert tens-of-thousands of videos into web and mobile outputs overnight, for playback across a variety of devices.

Most importantly, the end product is a very high performance platform that facilitates the creative output of its users. Joseph Gordon-Levitt, or “RegularJoe” on HitRECord, said, “Since working with Concrete Interactive and Zencoder, HitRECord’s video upload process has been smoother, the quality is excellent and processing times are really quick.”

Software Quality

What is Software Quality?

If you speak of software quality, what do you mean?  Product managers generally mean they want their features to work as designed across all target platforms.  Project managers want software to be completed on time and on budget.  Executives want customers to pay good money for a good experience.  And software developers want to build efficient code that gets deployed to their user audience.  In discussions with my clients, that’s usually about as far as it goes, “We want high quality software.”

In this article, I discuss ways to dissect software quality into six relevant areas: ruggedness, architecture, performance, scale, security, and process.  Each of these aspects of quality can then be prioritized, and following each area I highlight actionable ways to improve (or take shortcuts) in your software project.

Download this article as a PDF

Time. Features. Quality:  Pick Two.

When asked, “What is most important to you for this project?  Time, features, or quality: pick two,” almost everyone these days will actively choose to have a software project come in on time, and be of high quality, while accepting a somewhat more limited feature set.

But maybe this software adage has become as outmoded as the waterfall model. After all, the time we apply to a software project can be shorter or longer.  The features can be many or fewer.  So how can we match software quality in its manifold aspects and degrees to the goals of a project?

First it is necessary to realize that there is no one such thing as “high quality software.”  Quality, when it comes to software, is a way of saying how well a program solves its goal problem.  Let’s break that down into practical areas, since almost all software projects must face choices for budget allocation.


Software ruggedness is most commonly, and mistakenly, viewed as overall software quality.  In short, rugged software is written correctly, without bugs or user interface flaws, and works well across all its target platforms.  Building rugged software is probably the most widely understood software development practice.  Developing rugged software typically involves human force approaches such as manual quality assurance testing, bug tracking systems (eg. Fogbugz, Lighthouse, Bugzilla, Jira, Trac).

To ensure a software project becomes rugged, most software development teams “put it to the test.”  An adversarial practice is promoted between QA testers and developers.  This is often viewed as healthy, since many developers tend to label a feature as completed and move on to implementing the next ticket in their queue before engaging in the arduous task of cross-platform and stress testing.  In addition the practice of automated testing, using tools such as Selenium, Fake or custom scripts, aids the manual processes, but does not reduce the force required, it just shifts the human testing burden on to a new automated test construction burden, which in turn may have inaccuracies.


The single most important aspect of producing high quality software is matching software architecture to its problem domain (read Domain Driven Design).  At times the ultimate domain is not known, such as when a start-up company tries a new concept in the marketplace.  Often the iterative nature of market feedback, combined with an agile software development process, results in patchwork architecture ill-suited to the adapted domain.  Refactoring is the process by which a new software architecture is put in place of an existing one, containing the same feature set but, with increased capacity to solve problems in a new domain.

Refactoring is often seen by product managers as a costly and time-consuming enterprise that developers want for “code cleanliness” but with dire consequences on schedule and budget.  Yet, without refactoring a “dishes in the sink” approach can become endemic to the team mindset, wherein another dish, or in this case a poorly architected feature, gets added to the pile until a major reckoning is required.

Agile methodologies reduce the need for major refactoring by dissolving it into a relatively continuous process done along with the tasks of each sprint.  By shortening milestone deadlines into sprints, say three or four weeks, and reconciling the architecture improvements needed for each milestone, a clean household is maintained, and software architecture is built up continually to match the next few milestones.

  • Enforce use of Design Patterns: have developers do brown bag lunches, put this book on every developer’s desk.
  • Code up architecture for the current release.  Draw out architecture for the next two releases.


When it comes to massive database crunching, 3D game development, or scientific computing, careful attention is normally paid to algorithmic performance (as opposed to application scaling, addressed below).  However, in the course of building web applications, 2d flash games, or mobile apps, performance is usually examined when it becomes an issue.  This could be when the number of sprites in a flash game slows rendering, when mobile memory overflow causes crashes, or when web database queries become unacceptably long.  Code performance is another area where attention to quality at the right level should be built in as solutions are developed.


In contrast to performance, scale is often considered at the outset of web application projects, where eager management teams assert the need for servicing hundreds of thousands of concurrent users a la Twitter.  Technologies such as Ruby on Rails, Heroku, Google App Engine, Virtualization, and Amazon EC2 make scaling web applications easier than ever, and there is very little development cost to throwing more hardware at many common problems.  Of course, database design, server APIs and application server caching schemes go a long way to reducing these service costs by using them more efficiently.


Probably the most overlooked area of emphasis when developing a new software product or web service is security.  Frequently security breeches are recoverable, except the damage done to customer opinions (take the recent Sony debacle).  Life does go on (usually) after getting hacked, having a Distributed Denial of Service (DDoS) attack take down your site or application access for a time.  Scrambling to plug holes is the normal route.  But as with all other areas of software quality, a few simple steps at the beginning or middle of the development cycle can prevent the vast majority of infiltration.  Spending a day or two on threat modeling, updating security patches, and reading documentation about how to defend against common attacks are equivalent to locking your door when you leave the house: not impenetrable, but likely to encourage the attacker to move along to the next property.


Light enough not be burdensome, sophisticated enough to fit the tasks at hand, software development processes should fit the team, the company and the product.  Easier said than done.  Modern processes such as Agile overturn decades of doctrine involving heavy process such as lengthy code comments and prolonged design cycles in favor of iteration and well, agility.  The best software processes are fun, and since development teams are human, it is easier to convince them to do fun things than arduous ones.  The danger of a methodology such as Agile, or goal definition such as minimum viable product as to use as an excuse for slipshod project management and code practices.  To find balance in this realm is to focus on just what is important and have the right toolset to support just that narrowest of procedures: daily scrum meetings, hand-drawn feature sketches, presenting paper prototypes to potential customers, continuous deployment tools like Hudson and Capistrano.

  • Inculcate Test Driven Development into your process.
  • Use fast, analog approaches where possible: whiteboard, stickies, physical calendar on the wall.
  • Draw paper prototypes by hand (or with a ruler) and iterate frequently.
  • Tell your project manager to scan each design iteration and post to a wiki page.
  • Go to a cafe and buy strangers lunch in exchange for spending 5 minutes playing with your product on a laptop or phone.


It is my hope that by developing a deeper working definition and understanding of these six aspects of software quality, software projects will avoid many quality-related pitfalls, and make better decisions about how to allocate effort.  It isn’t necessary to spend time on every one of these areas, but it is necessary to consciously decide whether or not to.