Introduction

Architects and developers approach our craft from two different perspectives. One perspective is the project perspective. The project perspective takes one specific business challenge and uniquely creates a software solution for that particular problem. Usually the architect starts with a blank canvas and interviews the users. The developer takes the notes and diagrams from the architect creates and codes the solution starting with a fresh, blank screen.  There is discussion, testing, training, and hopefully satisfied users in the end with a custom project.

The other perspective is the product perspective.  The architect suspects a community of users have a need. Some form of market research is done. The architect designs features to fit the guessed needs of the target group. These features are not all-inclusive. In other words, some users would use one group of features and other users would use different features. The design is more demanding as the system must be open enough to accommodate different users using the software in different situations.

Not only must the architect and developer verify that one process doesn’t break another process, but the professionals must keep one feature from confusing the user of another feature. Let’s say, for example, that a real estate listing software has one set of functions to help the real estate agent list and sell property. It should not have a another set a functions that make the real estate agent completely unnecessary and not recommended. Software products must have a clear focus in its intent.

The demands on the developer are greater when they are working from a product perspective than working from a project perspective. Product classes and methods are much more generic and inclusive.  For example, dates must include all formats. It allows one user to input dates as 7/4/2022 and other user to input dates as 2022-07-04.  Holidays might need to be configurable. Holidays might include July 4 or Canada Day. Product based code is centered around configuration settings. Configuration allows one user to celebrate July 4 and another user to celebrate Canada Day with the same software code.

Testing demands are also greater from a product perspective. The heavy use of configuration to control software behavior greatly increases the alternatives to test. As anyone with testing scars knows, it is the combination of bug triggers that are hardest to detect. Your program might pay someone holiday pay if the holiday is on a weekday. But, it might fail if the holiday falls on a weekend. You must test for all days of the week.  Your software might know that 2022-03-06 is Sunday but not know that 3/6/2022 is also a Sunday. So, as you can see, it greatly increases the required tests when you have highly configurable software.

When to Use the Pure Perspective

There are obvious times to solely use one perspective. Over the course of my career, I have written thousands of kludge code solutions that ran once to solve one particular challenge.  It is foolish to spend any time treating those incidental tasks like a product. A single run task should be coded in the absolute fastest way as long as it gives correct results. Time is money.

A product should never be treated like a project. After creating TimeClock which I sold nationally through a network of dealers and TimeClock Lyte which I sold internationally, I can tell you plainly that users and dealers will find creative ways to use your software in ways you did not expect when you were coding.  I had no idea that there would be dealers that would create after-market products that would tie into my software. One of my dealers created a barcode device and another dealer used my software to track work tickets. Having a configurable product allowed them to use the software for those purposes.

Make your product as open as possible. Give your customers choices. Sales are like getting a job. You can get more jobs if you are open to working anywhere in the United States instead of limiting yourself to anywhere you can walk to from your home.  An excluded choice is a lost sales opportunity.

Placing in the Middle

Most of us, if not all, spend the majority of our time working on projects instead of products.  I have produced only six commercial products over the course of my career: TimeClock, TimeClock Lyte, BryShell, DbDelta, and Property Presentation System.  I have created many hundreds, maybe over a thousand, software projects over the last 35 years.  These projects are on a continuum between ‘kludge’ and multinational software product with varying degrees of being project-or-product.  How should we treat those projects in the middle?

• Software that will run one time with you as the user. That is always a kludge. Forget about beauty or documentation. Forget about configuration. All that matters is how few keystrokes you need to get that one run with the right result.
• Software you will run one situation multiple times. That is almost a kludge. You might spend a little time documenting and making the code understandable. Everyone of us has looked at old code and ran to the language documentation to jar our memory. Try to avoid that situation. Still, do not spend too much time on making it ‘pretty’. Just worry about it working and making it easy to understand.
• Software you will run for different situations.  Discuss and think of all the different situations. Make a configuration option for each of those situations. Test for those situations. It is easier to do this on the front end instead of listening to the heated demand for ‘the report’.  You are now more than halfway between project and product perspective.
• Software that will run for different situations by others within your company. This is almost a product. The only real difference is the distribution scope and you all work for the same company. Also, the ROI is almost always lower with an internal project-product than a commercial product. So, get a feel for how much you can invest and still show a internal profit. Spend as much time as possible understanding the different groups. Make it as general as possible. Test as broadly as possible.  Document to a flaw. I put the emphasis on documentation because that is where most professionals without commercial experience fail. Documentation.