Software is made up of code. The code is written by software developers. This article’s purpose is to debunk the idea that when you need software, the only thing you need is a software developer.

Making good software is not simply a matter of writing code, just like getting high quality print products out of your plant isn’t just up to your pressman. You need your front office team to capture accurate order details, you need your prepress team to prepare and proof the artwork files, you need your finishing and shipping team to do the post-production work to get the product to the right customer on time.

Just like the outcome of the print products you produce is dependent on what happens in front of and after the press run, software is highly dependent on the thinking, strategy, and design that happens before the code is written and the testing after the code is compiled.

Good software is determined by good thinking and design upfront and good testing on the back end. The upfront thinking is generally relegated to the product manager or product owner of the solution, the design is ideally done by a user interface (UI) or user experience (UX) designer. The testing or quality assurance (QA) is ideally done by someone with business context over the solution (e.g. someone who can predict what future users might do to break the system).

Poor software is typically the result of thinking a software developer can play all those roles simultaneously.

I have a very strict rule in the software projects we run, developers don’t make UI/UX decisions. Everyone on the team can give feedback, give their ideas, speak up but UI/UX decisions get routed to the UI/UX expert. It never ceases to amaze me how everyone on the team thinks they know best on the user experience. It also never ceases to amaze me when we hand off UI/UX challenges to our talented resource, she always comes back with solutions that remind us why we shouldn’t be making these decisions without her. The software user interface IS THE SOLUTION to the users. The decisions made there are critical to the success and adoption of the product.

What does software look like when developers make UI/UX decisions?

Look at almost every Print MIS solution for a clue. Crowded screens, hard to read areas, nonsensical grouping of tasks, lots of tabs, complex menus and submenus – you know exactly what I’m talking about! What is a good user experience – ironically, it’s a user experience that is not memorable because it doesn’t get in your way. You don’t remember the user experience because you just got what you needed done without thinking!

Creating good software takes a (little) village of well-coordinated folks. The resources I see as critical are the following:

  1. Product Owner / Product Manager: this is the person who is ultimately responsible for what the product becomes. They need to make the decisions about what gets into the product and more importantly what does NOT make it. Deciding what NOT to do is just as important. More is not better with software, yet more is always more complex. A product owner writes the user stories (requirements) that the developers use as the instruction manual to wrote the code). The product owner is the great translator between business challenges and technical solutions. This is a difficult job, when people are good at it, they create incredible software tools. When people suck at it, a lot of time and money is wasted building the wrong thing, solving the wrong problems.
  1. Architect: this is the person who is ultimately responsible for the technical quality of the product. This person might not ever write one line of code. This is the person who must oversee the people writing the code. The software architect is just like a building architect – they are planning out the technical design of the solution.
  2. UI/UX: a designer takes the users stories that are written by the product owner and then converts them to a user interface that takes into account any limitations of the platform you’re building on. The design deliverable is a picture of what the software will look like and notes on how it will behave (e.g. when you click this button, this action happens). And ever more important every day, when you look at this page on your mobile device this is how the design “responds” to the narrow screen – mobile is becoming the dominate internet access point. Don’t design anything that isn’t fully responsive to all screen sizes.
  3. Developers: the developer or developers are the folks that actually write the code. They consume the user stories and write code that ideally solves the challenges described by the product owner. The developers can have a real positive impact on the product quality based on their careful interpretation of the user stories and the quality of the code they write. Their ability to access the product owner is key to their success as agile programming is not heavy on documentation so it relies on daily communication between product owner and developers.

I often try and talk printers out of building custom software because I know to do it well, it takes a small village and that means time, effort, and investment. There are many reasons to build custom software or what I like to think of as assembling best-of-breed solutions to solve unique business challenges. For example, if you’re in a very specific niche business and you want a business-to-business ecommerce solution that supports unique workflows. I would never suggest you start from scratch.  I would suggest you license or use open source software for all the “expected functionality” like carts, user authentication, catalogs, etc., then build what makes you special on top of that technology. This approach limits your investment in custom software while still giving you the freedom to solve your unique challenges.