One of the most fun and interesting parts of consulting is the diversity of business types that you get to interact with. I believe that this is unique to building software and hardware solutions: not only is tech ubiquitous across industries, but good software has to be created with a solid understanding of the rules of the problem it solves.

People tend to think of pure software businesses when they think about the tech industry, but it’s not all apps and e-commerce. Lots of companies need internal tools to streamline their own businesses, so a large amount of software (perhaps most software) is not written to offer to the public.

Two of the companies I had worked for when we started this company did consulting, and of course, Rekka Labs is a tech consulting business. I’ve had the opportunity to write code that powered tools for education tech, animation, energy production, warehousing, and retail, among others, in addition to more typical software offerings like e-commerce, advertising, and social media applications. This may not be a universal taste, but I absolutely love learning what problems are presented by the sometimes chaotic atmosphere in a warehouse, by the different types of soil and their impact on oil pipeline coating, or by the complex distribution of funds behind large-venue ticket sales.

Useful Software Represents Domain Knowledge

This is certainly universal. If you take a look at any piece of software that has stood up over the years, you will find that the code is a representation of knowledge about a process and the domain in which the process is carried out.

That may not sound quite so obvious, but it is a necessary, direct consequence of an obvious fact: the tool fails to be useful unless its creators understand the way the tool is used and why the tool would be desirable. If the creator understands that and is able to apply the necessary skill to create the tool, the tool embodies knowledge about the process. A tool that does not embody this knowledge does not turn out to be useful: there is a mismatch between the process people want to carry out and what the tool can help them accomplish.

In simpler and more concrete terms, a screwdriver is the manifestation of knowledge about the process of driving a screw. You want to apply torque to turn the screw so that it is embedded in the wood. The design decisions that apply to a screwdriver are representations of several pieces of knowledge about this process. The head has to match the screws, the tip may or may not be magnetized, the handle can be round or angular, with deep grooves or shallow, and the handle can be smooth, textured, or covered with rubber. All these decisions rely on knowing a lot about thew screwdriver’s use:

• What type of screw you are driving?
• Should the tip be magnetized? Does it need to be used near equipment sensitive to magnets, or are the screws too heavy for magnetized tips to be useful?
• What are you driving the screw into? Does it have to pierce wood or drywall, or are the screws driven into holes that match their threading?
• How confined is the space where the screw is driven? Is there plenty of space to work with, or is even the user’s hand going to be hard to get in?
• What sort of grip is convenient? Is the user going to wrap their hand around it, or hold the handle in their fingertips?
• How long the screwdriver is going to be used? Does it have to be comfortable even after being used all day, or does it have to be convenient for intermittent use?

That’s just a small number of factors that differentiate the type of screwdriver I keep by my desk for computers from the type that lives in a construction worker’s toolbelt or the type that comes with a repair kit for eyeglasses.

The creator of a tool has to understand very clearly how the tool is used. Have you ever used a bad screwdriver? Do you have any appliances in your kitchen or garage that you never make use of because they aren’t matched to their purpose?

Have you ever had to fight with useless software?

Make Sure the Creator has the Domain Knowledge

The first thing you have to do when creating a tool, whether you are a developer, you are managing developers, or you are hiring us is to make sure that the creators of the tool understand the problem the tool is supposed to solve and how it will be used to solve this problem. This is one of the benefits of user stories: they are phrased as an expectation a tool’s user has of the tool. What the user is going to try, what they expect to result, and why they expect it.

But you can’t stop there. The creator of the tool has to understand the entire context of the process to create a really great tool. In some cases, the tool might be able to bridge the gap between two processes, or a different tool might solve the problem even more effectively.

For example, when we built DailyRead, we were chatting with our client about the process of writing articles for the site, and he mentioned that there was an external tool they had used to get various metrics about the text, like the Flesch-Kincaid reading ease or the SMOG index. They were copying the article and pasting it into this tool. When I found this out, I almost fell out of my chair. Manual processes like that are always a red flag, but it never occurred to the client that it would be possible for us to integrate that functionality directly into the editor. We built the feature, and it turned out to be fast enough that it could be done in real-time, while the article’s author was typing. (This was distracting to authors, though, so we turned it into a button.)

How to Make Sure It Works

There’s absolutely no subsitute for close communication between developers and users. Full stop.

Implementing that optimally is the only real question. This brings me to another great point of software: it’s easy to iterate and improve designs, certainly much easier than with physical goods like screwdrivers. Steve Wozniak remarked that playing with the color scheme for Breakout was much easier in software than hardware:

I called Steve Jobs over to my apartment to see what I’d done. I demonstrated to him how easily and instantly your could change things like the color of the bricks. Most importantly, in one-half hour I had tried more variations of this game than I could have done in hardware over 10 years.

He ended up with a color scheme he loved because he only had to change a number in the source code to try it out rather than replacing or rearranging physical chips on a board, meaning that feedback was nearly instantaneous. That’s the theoretical limit for a team: the user, the designer, and the developer were the same person. The closer we can get to that limit, the better the product is. In this case, Apple ][’s BASIC is still fondly remembered, and Woz’s version of Breakout had a very strong influence on the hardware and software of the Apple ][, which was the machine that started Apple on the path to being the tech giant it is today.

Our process was designed with domain knowledge at the middle. We start by talking about the problem, then talking about the business to understand the domain, and then talking about potential solutions before we get to the task of producing a spec for the solution. Throughout development, we keep communication and feedback at the forefront, and this ensures that developers’ understanding of the problem and the problem domain is constantly refined, which is the best way to ensure that the product is great.

The only way to have a great tool or a great product of any sort is to ensure that everyone building it really understands it. So the best team you can hire is a team that works hard not just on your product, but also on understanding your product and how it fits into your business and your users’ lives. Get started with that team.