Volume 30 Number 12
Upstart - Going Critical
By Ryan Donahue | November 2015
A positive work environment is a great thing. It keeps people happy, which keeps them motivated and productive. When people feel good about their work, they go home feeling more fulfilled at the end of the day, and come back eager to do work that gains them more praise. This virtuous cycle can become a trap, however, when it enables a poorly designed feature into your software, or even worse, poorly designed software into your customer’s hands.
To slip that trap, organizations must be able to engage in constructive criticism. If team members don’t feel comfortable providing constructive feedback to others on the team, it won’t be long before those criticisms come from angry customers, outraged over poor-quality products. The fact is, an issue not addressed in development will very likely impact product value in production and, ultimately, even damage your brand.
There is no sadder moment for a developer than to read a comment on Reddit complaining about something he observed before launch, but could do nothing about. This is something the game developer community has struggled with in recent years, with many large franchises pushing out high-profile titles that were, frankly, unfinished. Electronic Arts is a case in point. The difficult launch of its “Battlefield 4” game last year hurt the company’s stock price and produced a shareholder lawsuit. Now it seems we’re seeing more and more delayed game releases, as gamers refuse to line up to purchase new titles the way they had in the past.
Might early critical input during development have spared Electronic Arts and other game publishers a lot of trouble? Perhaps, but in a world ruled by ship deadlines and marketing target dates, the decision to delay a release to rework code is a tough one. It would help, perhaps, if there were a metric tracking the level of internal satisfaction for any piece of software in development. If that metric were to drop below a certain threshold, the product could be delayed until the issue is addressed, restoring internal satisfaction to an acceptable level.
Even if such a metric could be developed, the root issue remains: Modern software is often constrained by ship deadlines that create a hostile environment for critical input. It’s hard for a developer to constructively criticize another’s work, when everyone knows there’s no time or resources to do anything about it. It’s also important to note that criticism can go too far. If a company’s culture encourages employees to rip on each other’s work, it can create a toxic environment that leaves people demoralized and impairs productivity.
Ultimately, developers can only control what they control. And a large part of that is their own reaction to received criticism. Too often people dismiss criticism. We all need to understand and accept that while we will naturally have a bias toward our own opinions, those offered by others are just as valid, and are often important in finding better solutions.
Like anything in life, the key is to find a happy balance. Organizations that sustain a culture of positive reinforcement, and support a process that allows teams to act on received criticism, are much more likely to produce high-quality software than those that shun these activities. And it all starts from a simple attitude adjustment. If people in your organization make the effort to support others’ work, while valuing well-articulated, constructive criticism, it can transform your organization into a more productive and open workplace.
Ryder Donahue is a software developer engineer at Microsoft. Originally from the Hawaiian Islands, he now resides in Redmond, Wash., with his fiancée and their cat, Marbles.