Log In | Become a Member | Contact Us


Market Intelligence for Printing and Publishing

Connect on Twitter | Facebook | LinkedIn

Featured:     Print 2017     Production Inkjet Tools & Resources     Industrial Print Analysis     European Coverage     Conversations on Print Podcast

Commentary & Analysis

Hiring a Developer Does Not Get You Good Software

Building good software takes a (small) village of people with distinct skills sets. Don’t try and build software with only a developer, you’ll end up with software that only developers will want to use!

By Jennifer Matt
Published: February 15, 2017

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.

Jennifer Matt is the managing editor of WhatTheyThink’s Print Software section as well as President of Web2Print Experts, Inc. a technology-independent print software consulting firm helping printers with web-to-print and print MIS solutions. You can reach her at jen@whattheythink.com.

 

Discussion

By chris jordan on Feb 15, 2017

Great article by Jen. Like her I try to talk printers out of building their own software. It is not too difficult to build the first version of an application, but developers get bored very quickly and are motivated by the latest tech, not supporting different versions of a product. I started life as a programmer and have worked with many development teams.

 

By Jennifer Matt on Feb 15, 2017

Chris,
This is why assembling pieces of software to solve a unique business challenge is more interesting to developers. It gives them more diverse experience with more technologies.

For example, when customers have a unique w2p challenge that can't be squeezed into a commercial web-to-print solution, we will take a platform (CMS + ECommerce) solution like EPiServer and then integrate a composition engine behind it (e.g. Chili, XMPie, PageFlex, Silicon Publishing's Paginator, FusionPro). This combination allows the business to buy into the roadmaps of CMS, Commerce, and composition then just layer over the customer workflows that make them unique.

Its the best of both worlds, you don't waste time and money building "expected functionality" but you have the flexibility to present any workflows required by your unique business challenges.

It is not for everyone. It is a long-term investment and it requires a qualified team to maintain. It can be a huge differentiator when done well.

The long-term costs need to be considered.

 

By Jennifer Matt on Feb 15, 2017

Another comment came in through email that I think is worth noting here.

Look around your business. Do you have mission critical software that has a single point of failure? I'm not talking about servers, I'm talking about the fact that there is (1) person who knows how the software works because they wrote it.

People like to create. Having an IT person create your business software sounds like a good investment - you keep paying their full-time salary and somehow they find the time to BOTH do their job and write this software solution. It is a risky proposition.

Here are some ways people try and mitigate the risks:

1) Documentation (doesn't work, b/c the developer isn't good at writing documentation) and it is never kept up to date b/c he doesn't have the time to write code and document what he's doing.

2) Hire a junior guy and get him trained. A little better approach but then you're spending all this money on the junior guy and the time of the developer to train the junior guy. What are the chances the junior guy stays with you long-term?

It is better to base your business on a software solution that is backed by a software company, that is widely used in the marketplace (so you could find others that have experience with it). This is the most sustainable path.

This path requires you to be flexible - the success of your business with software is dependent on your ability to flex your business to work best with the software. The minute you start trying to change how the software works - your ROI will drop. Many people think building software is great because you have full control over how it will work. Full control means you have to own everything about it including a disaster plan for when the (1) person who wrote it wins the powerball lottery and heads to the beach ;-)

 

By Louis Caron on Feb 15, 2017

I have spent years on both sides of the software development discussion. The one thing that I have learned is program coding is the easy part. The hard part is the design and that requires ownership by the users. Users writing specs, in my experience, is a waste of time. Users reacting to prototypes or mockups is incredibly valuable especially when they are populated with real data.

During my project manager days, I found myself spending a ton of time telling the users to avoid telling the developers how to do their jobs and the reverse, telling the developers to listen and not tell the users how to do their jobs. At the end of the day, if the users do not like or find ways not to use the system, not matter how cool the programming is, it is a failed system.

To your point, the team has to include a combination of users and IT (UI, architect and developers). However, I always try to impress on the team that the users have to take ownership of the system.

 

By Robert Godwin on Feb 15, 2017

Surprised that Agile development has not been mentioned. Only way to go. My team consists of 4 domestic (US) developers plus developers on staff and remotely located both in the US and Europe. Without Sprints and Scrum Masters continuous deployment (CD) is not possible. Without (CD) you are already out of date.
So many developers are driven to hard code because it is fast. But the dependencies on a hard coded service make it a pain to replace/update. SOA is a better approach and allows for the fast changing development environment.
Creating applets, building systems…maybe a good idea. However, for many of the reasons cited in prior posts, that is fraught with support and updating issues.
Best to remember the adage “Software is never done.” If your core competency is printing, then software development is just an expensive, shiny object; a diva in need of constant attention; a harsh mistress.

 

By Murray Oles on Feb 15, 2017

Printers and prepress companies have been writing software for decades. Some are better than others. Since the mid 1980s the industry has defined its competitive advantage largely through process automation. When it comes to the quality of software that a developer produces, I refer you to Fred Brooks book, The Mythical Man Month. Software developers are like artists, you can give anyone a box of paints but that does not make them an artist.

 

By Mark Myers on Feb 24, 2017

Re-hiring a developer does not get you good software


Well, this is definitely a subject that is very close to my heart and I found the article extremely interesting as it clearly illustrates and highlights all the features I tried to include when I wrote back in 1995 and estimating and MIS system for my own company. I was using PSI at the time and when they introduced automated mail I added a mailing portion to my printing company that could handle 1 million pieces of mail a day. Looking for a more robust system I purchased logic which at that time was priced in the six figures and after finding it would not do the job I needed it for I returned the program and started to write my own in Excel.

I became so obsessed with learning and writing code that I hired a full-time manager from my company so I can sit in my office and write a program with the input from most of the over 100 people in my employee.

It took me almost 2 years to refine the program and achieve my goals of having the easiest to use user interface or UI so my sales staff could do a live estimate in front of the customer and walk out with the order. I built into the program protections and incentives for the sales force with an automated output that clearly defined what the customer was getting and at what price.

Salespeople from Xpedx, and Unisource convinced me to turn it into an executable program which I spent another two years until its introduction at graph Expo in 1998. When I came back from the show I basically turned the company over to my junior partners and have since then pursued improvements and innovations most of which came from customer feedback and for many years averaged about 100 improvements a year.

My background as an engineer and my more than 20 years’ experience in the printing industry without any preconceived ideas allowed me to create a completely new set of algorithms, which are the heart of any software, based on new ways of looking at the printing functions that produced from a single screen, fast accurate estimates which simultaneously created all the workflow documents necessary to greatly improve the efficiency of my company.

About two years ago, recognizing the need for an easy access cloud solution we created an entirely new cloud-based program and with 20+ years’ experience in the business simplified the user interface even more. Although it may sound simplistic we ended up with four short columns headed by the letters ABC, the first column contains all of the press options the second column B contains all of the paper options with three choices of ways to select paper, the third column allowed you to select all prepress bindery and special services while the last column contained the selected quantity and a complete automated description of the job is sent to the prospective client.

As an engineer, I had designed and built several buildings and was also drawn to your analysis of an architect planning a structure. As the project manager and the programmer I was easily able to implement your highlighted desirable element of the simplest user interface with complex structures driving the engine.

I also recognized a very important issue of the changing face of the printing industry that has brought a huge rise to digital printing with many included bindery features. These new structures now required many bindery functions to be part of the press functions and not isolated in a separate bindery table. This allowed our program EstimatorCloud.com to have unique pricing for bindery operations attached to each press with a unique identity and profit structure for each piece of equipment. Folding and stitching was no longer just a bindery function but needed to be priced separately for each piece of equipment which was easily accommodated by our new approach.

Again as project manager and programmer it was easy to see the interconnection you wrote so well about and was also able to achieve complete functionality from any mobile device and responsive, as you point out to all screen sizes.

Jennifer Matt explained that she was the president of Web2Print Experts so I think it would be interesting if the two of us could put together the first web to print solution for doing real live estimates not from templates. Since EstimatorCloud.com is written in open source language I believe we could create a real industry first.

Mark Myers is the President of Estimator Software LLC DBA Estimator Corp and EstimatorCloud.com you can reach Mark @ Sales@EstimatorCorp.com

 

By Robert Godwin on Feb 24, 2017

Mr.Meyers letter is quite a proposal, almost romantic!

 

Post a Comment

To post a comment Log In or Become a Member, doing so is simple and free

 

Become a Member

Join the thousands of printing executives who are already part of the WhatTheyThink Community.

Copyright © 2017 WhatTheyThink. All Rights Reserved