In-House Software: Risk or Asset?

HydroComp Web Log

[efficiency in motion for over 20 years]

In-House Software: Risk or Asset?
Miscellaneous Musings from the Technical Director

Monday, 19-FEB-2007 by Donald MacPherson - Technical Director

You read Stephanie's article from her trip to the SINAVAL show, in which she did her own musing about in-house software. For decades, HydroComp has commanded a market niche where our biggest competitive product is a potential customer's own in-house developed software. This may seem like an enviable position, but let me assure you that it is far easier to compare value with another commercial product than with in-house developed software, which often has a company legacy and is frequently perceived to be "free".

It is easy to take published formula and write software, but are the answers meaningful? What does a company gain by developing in-house software? What do they risk?

Perhaps a brief real-world example will be the best introduction. We recently had an interesting conversation about software with the sales staff of a propulsion equipment distributor (who shall remain anonymous). There were two principal themes that they shared - a) they were not confident in the answers their technical support staff was providing them with their in-house software, and thus, b) they no longer use software for any application sizing because then they would be liable for the recommendations. (Instead they let the boatyards order what they want without consulting them.)

To summarize - an equipment vendor felt that it was a better business decision not to provide "added-value" application sales services to their customers because they would become liable for the answer. All due to lack of trust in their in-house software. This doesn't sound like much of a business plan to me...

Unfortunately for them, the reality is that the boat builders have a similar thinking, and they will choose to go to the company that gives them the service. Let's face it, who is more likely to be better educated and have more experience in sizing the best piece of equipment for the application - the builder (who does maybe 3-4 installations a year) or the supplier (who may do hundreds and supposedly has a broader range of experience to help mitigate potential problems and provide the best overall recommended solution).

Let's ask some questions to help determine if in-house propeller and powering software is necessarily a business liability, rather than a positive contribution. You can generally get an idea about the potential risk by considering who is writing the software (e.g., the application sales engineers for propulsion equipment companies).

Are they educated in marine hydrodynamics?
Do they know how to model propeller cavitation? Or cupping?
Or the differences between the basic formula and the real propeller?
Do they understand the scope of the resistance prediction methods?
What kind of programming skills do they have?
Do they know how to handle potential calculation errors due to the way digits are handled in different countries (e.g., with a period vs a comma)?
Do they know how to provide user feedback during data entry so that the user does not accidentally enter a wrong figure?
Or data from a customer that they do not know is wrong, but clearly does not correspond to industry-expected values (the relationship between weight and length for a given hull type, for example)?
Or how to develop optimization algorithms in software?

If the answer to these questions is "no", then the software is risky. And, in most cases unless the company has a dedicated programmer with education and experience in applied hydrodynamics, the answer is indeed a resounding "no".

Risk aside, it is also a curious business decision to "roll your own" software. Now, I realize that any engineer has an issue with blindly using a tool that someone else created. I'm the first to want to "do it myself" so that I understand the underlying methodologies and techniques. However, I didn't feel the need to write my own spreadsheet - I use Excel. Or a database, or word processor. I use commercial statistical tools and plotting software, even though I could have written my own.

The business plan of an equipment supplier is to sell equipment. And reliable software is an important tool to sell equipment. If you had no alternative or if the available commercial software options were unreliable, then you need to write your own. If reliable commercial software is available that meets the needs of the user, then every hour spent in writing and maintaining software is an hour taken away from the company's financial mission - selling equipment.

So, how do you define "reliable"? In the absence of extensive in-house validation and testing, look for these few indicators:

1. A company with an extensive history and experience in the discipline. Do you really want to trust an integral part of your business plan to freeware from a "guy in his basement"? Or from a company where the discipline is not a priority but an afterthought? You need a deep and passionate commitment to R&D and development, as well as an active consulting business in the discipline.

2. A broad user base. Having hundreds of other users working with the software reduces your own risk in finding something unusual that has never been considered. It also provides the basis for ongoing new feature development.

3. A solid professionally written application. This should include help systems, integrated user feedback, and available and accessible technical support. You know, a nice, friendly, competent voice on the other end of the phone.

Remember, the phrase "you get what you pay for" is not just a cliché. Doing things cheaply can ultimately be costly if you can't run your business...