Why Good Developers Make Bad Software

Why Good Developers Make Bad SoftwareWhy is it that every time I deal with a developer or programmer, we always get into a battle between usability and function? I’m not calling every developer out on this, but those of you out there that are guilty of this know who you are. For that matter, the blame isn’t even the developer’s to begin with.

End users have no common sense whatsoever. At least, that’s the assumption developers should be making when creating user interfaces and working the project road map. Programmers work tirelessly to build something that does exactly what the project manager wants it to do, and often the original draft of a site submitted at this stage has what would appear to be groundbreaking functionality and/or a feature list a mile long. Unfortunately, these early development drafts typically lack the one thing the user is really looking for: a clean and easy user experience.

Here’s where the problem sits. The developer and/or programmer behind the scenes making things connect and work in the way the project manager envisions is rarely given the full scope of how things should look and feel when the project is complete. In fact, the tools used in a program are usually built before thought is put into how the user will use them. The project manager may have no clue as to how to create a user friendly website or program, and the false assumption that the programmer is supposed to know and understand how this works is often made. The end result is rarely pleasant for the end user.


I’ll start examples off with Google+. This is an incredibly robust social networking site with a number of features that were exclusive to the service when it launched. On paper, everything works as it is expected to and any kinks existing in the network are being worked out as users discover them.

The problem is, this site is clearly built by programmers and only after the tools were created was user experience taken into account. Yes, I’m making an assumption here as well, but that’s the only explanation I could possibly come up with as to why Google+ looks and works the way it does.

Don’t get me wrong here; Facebook suffers the same problems with the multitude of independently developed apps users are bombarded with on a day-to-day basis. Facebook itself was no award winner in the realm of design or user experience early on. It might even be argued that it is far from ready for prime time even today.

The problem here is that developers behind these sites are assuming that users have common sense. You have to, in almost every circumstance, cater to the lowest common denominator when appealing to the public with a website or program. If you’re appealing to a group of developers that understand logic and how many of these things work, that’s great. If you’re attempting to appeal to the massive public, you may want to rethink how software works.


You see a lot of this in video games. While much of the reception of a game comes down to personal tastes, it’s no surprise that extremely simple games like Angry Birds are dominating mobile platforms while more robust games with complex controls are failing to reach their potential. No doubt a PC-class adventure game would sell like hotcakes given the successes of these titles on other platforms, but the learning curve to manipulate a complex set of controls can be very limiting.

Look at the MMO world. Complex MMORPGs appeal to a limited audience, though the audience does indeed exist and appreciate the complexity of the game. EVE Online is one of the more difficult games to understand, and as such hasn’t quite reached the population levels of simpler games like Guild Wars and World of Warcraft. Don’t get me wrong, there’s plenty of room for strategy, but its the simplicity of the game that makes it appealing to a much wider audience.

Another example I would give is Second Life. While not a game, the virtual world is a developer’s paradise. You can script and sculpt just about anything you could imagine and make it a part of the virtual world. I’ve even worked with virtual television stations that broadcast live tv from virtual sets. It’s remarkable what you can do with the platform. Unfortunately, the UI and customer experience is difficult for people to get used to. Adoption takes place in the first hour, and it’s in that first hour many of Second Life’s would-be citizens give up.

So What Comes First? Developers or UI Designers?

Eddie Ringle, a developer and frequent contributor to LockerGnome, pointed out to me in a recent conversation about this issue, “Developers should always come before UX designers.”

This statement was in response to my having stressed the importance of finding out what you’re building before you build it. A house’s foundation and frame is great, but wouldn’t you want the architect to present you a model of what the house will look like before breaking ground?

With Eddie’s advice in mind, I’m led to believe that proper development should happen hand-in-hand. The best projects I’ve been a part of to date happened with the developer and designer sitting next to each other, having full and open conversations throughout the process. There was never a question as to where or how something would happen, and the project manager’s role was as the facilitator of the creative process.

Why Project Managers, Clients, and Business Owners Are Often to Blame

The client or owner of a project is usually the person with the least actual understanding of how things work. Sad, but true. Small businesses are riddled with graphics designer relatives and social media experts. This creates a disconnect in the project where the developer, designer, and the “expert” aren’t taking part in a two-way conversation. The expert is telling the developer what to do, the designer what to draw, and the result is only as good as the expert.

I have seen excellent programmers turn out crappy projects, brilliant designers create disasters, and all while the project manager has been “involved” every step of the way. Having been in the room while a business owner tells the developer one thing and the designer something entirely contrary, it’s hard to believe this doesn’t happen more often than it should. The client and/or manager should review drafts, not progress.

My advice: when you hire a developer, trust them to build the frame and give them access to the designer. The project manager, client, or owner should list out everything they want/need in order of importance and hand that to the team. The team then has the responsibility of coming together and building something that meets those needs. There are few things a project manager can do worse than interrupt the creative process by injecting changes before seeing the draft. I know it’s hard, but sometimes you have to trust that your team knows what they’re doing.

5 comments On Why Good Developers Make Bad Software

  • job for nine months but last month her pay check 

  • My ńeighboŕ’s mŏther-iń-ląw Maḱes $8O houŕly on the laptoṗ. She has bėėn out of w0rḱ for 7 Ṁonths but ląst Ṁonth her ińcome wąs $8734 just worḱińg on thė laṖt0Ṗ for a ƒew hours. Gŏ to this web siṫe and ŕead morė.. CashLazy.&#99om

  • My ńeighboŕ’s mŏther-iń-ląw Maḱes $8O houŕly on the laptoṗ. She has bėėn out of w0rḱ for 7 Ṁonths but ląst Ṁonth her ińcome wąs $8734 just worḱińg on thė laṖt0Ṗ for a ƒew hours. Gŏ to this web siṫe and ŕead morė.. CashLazy.&#99om

  • My ńeighboŕ’s mŏther-iń-ląw Maḱes $8O houŕly on the laptoṗ. She has bėėn out of w0rḱ for 7 Ṁonths but ląst Ṁonth her ińcome wąs $8734 just worḱińg on thė laṖt0Ṗ for a ƒew hours. Gŏ to this web siṫe and ŕead morė.. CashLazy.&#99om

  • What are we getting spam in the comments now?

Leave a reply:

Your email address will not be published.

Site Footer

Sliding Sidebar