If you want to hear print owners complain, ask them about software. I don’t think this is unique to the print industry. Most businesses are frustrated with their business software. I could write an article about what people complain about most (that would be redundant and boring). I could write an article about what vendors could do better (I think we’ve covered that in other articles). What I want to write about is the actual process required to build good software; because I believe if printers understood the software development process better, they could influence it more effectively. The result would be exactly what printers are looking for – software that returns more ROI to their businesses.

One of the best analogies I’ve heard to describe the software development process is comparing it to building a home. We all understand that building a nice home first and foremost takes a translator who listens to what you want and then designs what is to be built (the architect). The architect is often supported by a structural engineer to make sure what was designed can be safely built (does not fall down). Once the plan is agreed upon, including full visuals and now with modern software 3D walk throughs, the building can begin. The builders include the primary labor (contractor) and specialized labor (electrician, plumber, etc.).

The final step for building a nice home is the inspectors who make sure everything is up to the current building codes. These people come and check the work of others against established criteria. If your home fails to meet the criteria, remedies are suggested and labor is deployed to bring the home up to code.

Building good software is like building a nice home.

The translation between what you want and what will be built in software should be done primarily by a product manager and secondarily by the software architect. The product manager is listening to the business challenges and then translating them into the features and functionality of the software. The software architect then layers their knowledge of how the software will be structured (like the structural engineer on a home). Your software architect is making sure the software will work and designing the interactions between user experience, database, and external systems.

The specialized labor includes the user experience (UX) / user interface (UI) designer. The user experience is how the users of the software interact with it. This is a specialized skill. The biggest mistake I see with software projects is when the software developers make UI and UX decisions. This would be like your contractor saying he could handle all the electrical and plumbing in your house, no need to hire specialists. The UI/UX of software is the most important part. The reason we have so much software that is frustrating to use is that software developers made the UI/UX decisions. This is also why most software requires a decoder ring to figure out how to use it. A decoder ring is a translator between what it says on the screen and what it does. How many times have you heard someone say, oh that feature that is called “X” really does “Y”! Why the heck didn’t you just name it so we don’t have to have a manual, documentation, or massive amounts of training?

The labor for software development is the coders. The software developers take the instructions from the product manager and turn them into working software. They are like the contractors building your house. They should NOT have to be delayed by having to make a lot of decisions – the decisions should have been front-loaded in your plans. Contractors are not expected to decide the height of the ceilings in your basement. Software developers should not be deciding what to name a button or whether functionality is displayed in a pop-up modal window or via an error message embedded on the screen. The UI/UX designer should decide all of this because they are thinking about the human user not the human who codes (who is generally not your target market).

How should this new knowledge impact you when you take on software development projects or you’re giving feedback to vendors about their software products?

Recommendations for Printers

1. Describe the challenge/problem instead of suggesting a solution

When your house has a water leak, you call the plumber and say, “water is leaking above our stove which is right under the upstairs shower – can you come check it out?” You do not say; I think you should re-route the main water line from downstairs to upstairs or another other proposed solution. You describe the problem in the form of the symptoms you are witnessing. Your objective is obvious – we would like the walls and ceilings of our home to be dry.

When software doesn’t work the way you want it to, we don’t describe the symptom, we race off to recommended solutions. I’ve heard printers say; “could you please create a download button on this screen that downloads all the data?” This is a proposed solution. I don’t know what problem you’re trying to solve. This is a real example so I’ll tell you what we did. We did NOT code a download button on the screen; because when I asked what are you going to do with that data, the printer said. “I am going to combine it with images of all the items on the screen, create a spreadsheet and send it to my customer for review.” So the problem they wanted to solve was the ability to view a set of data in multiple ways – one as a list, one as a grid with images. We implemented multiple views on the screen as the solution to this challenge. With one click the customer could see a list, with another click the customer could see a grid view with thumbnails of all the images associated with the items. If we hadn’t asked what problem they were trying to solve, they would have wasted their money and our time building a far less effective solution.

2. Understand that writing code is about one-third of the software process

When software is needed; so many printers think all they need is a software developer. Then they wonder why the developer built something that doesn’t quite solve their problem, is difficult to use, and looks awful. You are asking the coder to play all the roles. This can be done. For very small projects it doesn’t make sense to spend the money to have all these different skill sets. Look for a developer that is well rounded and can do all the skills well. For anything serious, larger scale you must get access to the specialized labor (especially the UI/UX role). You can translate your needs into requirements and have someone design the pages before you even look for a developer. When you have everything scoped out its so much easier for a developer to estimate the project. You are not a UI/UX expert, everyone seems to think they are good at this. You probably aren’t.

3. Software takes time to do well, more time than you think, rushing it creates a mess

Everyone is under the gun. Your customers are demanding from you and often you can just ask your team to work overtime or add another shift. Software is less easy to scale, especially larger projects. There are books written about the failed attempts to scale software projects by throwing more people in the mix to speed it up “The Mythical Man-Month”. A software project requires context. When you add more people to a software project you slow it down temporarily because the people with context have to stop working and provide context to the new people.  This makes software frustrating, it never seems to deliver near the pace of our expectations. This isn’t software’s fault. The expectations are set by sales representatives (who earn commissions when you buy their software), quarterly earnings (if you’re a public company), and support teams who are desperate to please frustrated customers. Software expectations are the classic overpromise and underdeliver. When you’re talking about next year’s release on the trade show floor this year, when it really comes out twelve months from now -  it will already be a disappointment.