Vision Based Hiring

Engineered Software has been expanding our team these past few months and it has been a pretty exciting time. Since September, ESI’s vision for the future has continued to mold and evolve as our team rethinks how we provide our customers with innovative tools to increase the efficiency of fluid pumping systems through superior pump selection and system simulation software.

We’re not only looking at what products we’re developing, we’re also looking at how we do what we do. We are examining how we communicate with our substantial customer base, how we strive to provide world-class customer service, how we work through our Product Life Cycle, and how teams are structured and interact to produce an innovative and robust development process.

Part of the discussion is around what we want to change, another component is around what gaps exist between the skills we have now and what will be needed in the future. To pursue these future goals, we’ve embraced a culture which speaks up about solutions; pursues a collective, analytical response to problem solving; and provides thoughtful and honest retrospectives. As a whole company, we  strive to be visionaries who weave ideas with the ideas of others, with a management team who works to create a nurturing environment to support and empower our teams.

We’ve also worked hard to identify new skill-sets that will propel our mission, determined to hire people onto the team who possess these skills, share our company culture and believe in our vision. During the interview process, we know when we’ve found someone who fits, because they go from interested in the job to really wanting to work here.

Overall, change is hard, it’s confusing, we’ve all been there and sometimes it’s just not fun….but change is also exciting, empowering and inspiring. And what you’re left with, if you do it right, is a springboard for some exciting future endeavors.

- Christy Bermensolo, CEO

---

We would like to introduce our readers to the guest author for this month's entry. This post was written by Engineered Software's newly appointed CEO, Christy Bermensolo, and we would like to welcome her to the new role.

Christy Bermensolo began with Engineered Software in 2006, and brings over 16 years of engineering and management experience to her new position. To learn more about the new leadership changes at ESI, VISIT HERE.


We are also hiring right now and if you are interested in relocation to the Lacey, Washington area, check out our available positions here:

PIPE-FLO Looking Forward

Estimated Reading Time: 6 minutes 19 seconds. Read Later

Looking at the Past & Preparing for the Future

At Engineered Software for the last 30 years we have continually upgrading our products to take advantage of improvements in computer hardware, programming language, and operating systems, but the major focus of our updates has always been to better meet our customer’s needs. Over the years PIPE-FLO has been upgraded ever 12 to 18 months. Every 7 to 10 years we have a Milestone upgrade in which major program changes take place to take advantage of new technology. We are currently in the final stages of developing our latest Milestone upgrade, which has been three years in the making.

In the early years of computer programming, maybe the mid to late-1980s, software businesses never released version 1 because they believed customers would be hesitant to be the first adopters. Quite often, version 1 was a beta, and this was way before the public would be willing to use beta software. So, in 1982 we released PIPE-FLO version 2.

The major objective of PIPE-FLO 2 was to develop quality, shrink-wrapped software for designing fluid piping system that could be used on computers using the CP/M operating system, along with the recently released IBM® PC. The program was written in C-Basic and used Access Manager so we could take advantage of all ASCII terminals (all text no graphics).

We developed a variety of companion programs (NET-FLO, ORI-FLO, PUMP-FLO, and CON-FLO) using this technology; each capable of reading PIPE-FLO’s pipeline database. Another major first for PIPE-FLO was our use of a graphical interface. Using our NET-FLO/CAD interface and AutoCAD® by Autodesk; our customers were able to insert piping system information into an AutoCAD drawing. PIPE-FLO then read the information from the drawing, set up the piping system model, calculate the results and updated the AutoCAD drawings showing the calculated results. It was well received, but the major drawback was our customer had to own AutoCAD.

 

Windows the First Milestone Upgrade 

 

In 1985 Microsoft released Windows as a graphical interface. After completing PUMP-FLO™ for Windows in 1986, we started thinking of incorporating the Windows graphical interface into PIPE-FLO. To accomplish this, PIPE-FLO had to be completely re-written using the C programing language. During this rewrite we incorporated the functionally from both our existing PIPE-FLO and NET-FLO programs, in to a single Windows application which we called PIPE-FLO version 4. 

PIPE-FLO 4 utilized a commercial database, allowing our customers to build piping systems of any size while employing automatic backup protection. Version 5 and 6 were based on this technology and during this time we integrated the drawing of the piping system directly into PIPE-FLO. We also released our utility programs for pump selection, control valve selection and flow meter sizing programs as Windows applications with the capability of reading the PIPE-FLO’s Pipeline Database. 

Our customers really liked the integrated flow sheet drawing along with the ease of use offered by Windows. In talking with our customers, they wanted us to make it easier for PIPE-FLO to select equipment such as pumps, control valves, and flow meters. In addition, they wanted to share their project with others in their company as well as customers and vendors they work with.

 

Security, Integration, and Ease of Operations 

 

In 1998 we decided to embark on next Milestone upgrade, PIPE-FLO version 7, with a final release in 2000. During this major rewrite we decided to stop using the commercial database employed in PIPE-FLO versions 4 through 6 and developed a proprietary data structure for the Piping Project. Thus introducing the .pipe file extension type into the lexicon. This allowed us to speed up disk operations, create smaller project files, and allow for easier sharing of the piping system model. We also tightly integrated the three stand-alone utilities for pumps, control valves, and flow meters into PIPE-FLO.

Another major goal was to achieve consistency of operation with other Windows applications. For example we modified PIPE-FLO’s drawing tools to reflect the operation of common CAD programs such as AutoCAD®, Visio®, and Pro/ENGINEER, this way our customers already knew how our drawing tools operated. In addition, we made our list view to look and feel more like a spreadsheet providing the opportunity to sort the list, choose items to work on, and even giving them the ability to edit on the list. The PIPE-FLO Viewer program was also introduced allowing customers to share interactive piping system models created by PIPE-FLO Professional without the other individual needing the full PIPE-FLO program. Finally the X-Link feature allowed for two-way communications between PIPE-FLO and Microsoft® Excel®. 

Our customers continually provide suggestions on ways to improve PIPE-FLO. Recently we have noticed that many of their suggestions deal with workflow within their organization. For example, engineering firms wanted to develop their own customized reports and share information with other departments (both engineering and purchasing). Our customers at industrial plants were looking for easier ways to build a PIPE-FLO model using data from other programs. 

 

Third Milestone Upgrade

 

In 2009 we started working on our third Milestone upgrade. Our product development team had grown to five engineers, six application developers, and two test developers. To accommodate this larger team we needed to streamline our internal development process so we employed the Agile development process and integrated our program testing into every stage of product development.

Regarding PIPE-FLO, we determined the upgraded program must have the same functionality as earlier versions of PIPE-FLO, but we wanted to make it easier for our customers to integrate the software in their workflow processes. 

To accomplish this, our engineers started categorizing every customer support ticket and feature request looking for ways to streamline and clarify program operations, improve consistency, and provide the added features that our customers had requested. Next they started evaluating other commercially available software including engineering, business, and software development applications.

After reviewing the programs they developed a list of guiding principles for the Milestone upgrade:
   •    Minimize the use of dialog boxes whenever possible
   •    Increase consistency of operation within the PIPE-FLO program as well as other software tools used by our customers. (CAD, Microsoft Office®, engineering analysis tools, etc.)
   •    Make it easy for PIPE-FLO to incorporate new program features in the future

With this list of goals, our engineering team started developing “stories” for all existing PIPE-FLO features. These stories document how the feature worked, how the customer used the feature, the required data input, formula used to calculate the results, along with how the results would be used.

Once each story was defined they were reviewed by the developers to help them determine how the final program would work. With the big picture provided by the various stories, the software developers created “objects” that compartmentalized the task that can be re-used for the various program elements. This is mostly behind the scenes but manifests in the ability to add new features much quicker later on. The PIPE-FLO calculation engine was also compartmentalized allowing the developers to supply the piping system data to the engine, and then utilize the calculated results.

This required major revisions to ever stage of program development. Approximately half of the development effort involved building the internal program infrastructure to provide flexibility of the engineering units, develop the various program objects, and passing of information to the various objects. Once the infrastructure was developed the various piping system elements (pumps, controls, components, tanks, pipelines, etc.) were incorporated into PIPE-FLO using the pre-defined objects.  Using this approach the engineering team was able to work with the actual PIPE-FLO program through the majority of the development cycle with new program elements being continually added.  Using this approach and the Agile development process we were able to fine tune the user interface as new components were added.

The final step in the development process was implementing the user interface items. This included multiple object selection, the addition of the printed reports and graphs, along with the ability to extract and work with input data and calculated results.

Multiple object selection is one of the major new program features. In the most previous version of PIPE-FLO, you could only select similar items in a rectangular selection window and once selected the objects could be copied, deleted, or moved. In this upcoming milestone update, you can select a group of object in a rectangle/s, select individual items from the flow sheet, select individual or multiple items from the list view, as well as de-select items. In other words, our group select tool is identical in operation to group selection tools in CAD programs and Microsoft’s Excel. Once a group of items are selected you can copy and move the objects, edit the design data, change the text font, or insert a note in a single step. This feature even applies across object types. For example, in the new PIPE-FLO, both tanks and pipelines have fluid zones, using the multiple select tool you are able to change the fluid zone in the selected pipelines and tanks in a single step. 

Multiple object selection is just one of the many new and time saving features in the next release of PIPE-FLO.  In the coming weeks we will be releasing more information about the next release of PIPE-FLO, but the biggest secret is the name for the next release, for that you must wait.

Here's a sneak peek at the upcoming version of PIPE-FLO. Make sure to send me your comments and thoughts on the new look and feel. CLICK the image to view larger.

I Have a Problem with Issues

Estimated Reading Time: 3 minutes 48 seconds. Read Later

I have a Problem with Issues...

One thing I have noticed over the years is that the word problem is being replaced by the word issue. It seems no one has problems any more, we only have issues. (And don't even get me started on challenges.) For example, while watching TV the other night, I heard a news caster reporting on a Twitter outage as saying,

“Twitter users are experiencing issues accessing Twitter. Their engineers are currently working to resolve the issue.”

Since Engineered Software offers Software as a Service to our PUMP-FLO customers I understand the necessity for their website to remain up and running at all times. I also understand what it takes to maintain this up-time and what it means when there are unplanned outages. Knowing this, I would imagine that with their primary and backup servers down, and no activity on their site for more than an hour, the engineers at Twitter had a full-fledged problem on their hands.

I wanted to investigate the difference between problems and issues, so like all Internet aged people that want a quick “answer” to a question I did a Google search on "Problem vs. Issue." What I found was a lot of sappy crap written in forums that could be summarized as this; issues can be discussed and corrected, but problems were big and nasty and couldn’t be solved. (I once used that definition of problem in my differential equations class in college, but my professor took issue with that.)

The word problem, is still in limited use, but I have yet to hear a math teacher assign any homework issues.

I then decided to look up the definition in a dictionary so I went to Wikipedia®. They had usage examples of the two words but no definitions. I then clicked on their disclaimer page and found out they make no guarantee of validity. Since I feel as though my blog readers deserved a guarantee of validity, I decided to look up the definitions in a paper dictionary. Webster surely guarantees their definitions.

I went around the office and asked 15 people if I could borrow their dictionary. The responses ranged from, “Let me get my phone” to “What, is the internet down?” along with similar refrains. Only one person in our office of 35 had a paper dictionary and after he found a similar sized book to hold up his monitor he loaned it to me. It was a Merriam Webster’s Collegiate Dictionary 10th edition. One good thing Merriam Webster’s has a Website that lists their definitions as well, so if you have difficulty finding a paper dictionary in your office I have provided the following links to their Website.

Problem: http://www.merriam-webster.com/dictionary/problem

Issue: http://www.merriam-webster.com/dictionary/issue

The first thing I notice is that problem has only two uses, and they both relate to questions raised for inquiry or an unsettled question. This is a straight forward definition that can be understood by all.

Issue on the other hand, has NINE uses of the word, ranging from: the proceeds from a source of revenue, the action of coming or going, a means of going out, a financial outcome, a final conclusion or decision, a discharge of blood from the body, something coming from a specific source, and the act of publishing or officially giving out or making available. Item six on their usage list is “a matter that is in dispute between two or more parties.”

So how did we get to the point of calling our problems issues? It surely wasn’t to make the sentence easier to understand. For example, if someone says “I have an issue with my eye,” do they mean they are having a bloody discharge from their eye, or are they saying their eye is having a matter of dispute with their nose? More than likely, they didn’t want to upset anyone around them with their (possibly serious) problems.

I think people have stopped using the word problem because of our phobia with math. Just ask any parent of a high school student taking first year of algebra. Unless the parent majored in math, a physical science, or engineering, the typical response is “I really have issues with math.” What they are trying to say is if they must think too much about their kid’s math assignment they may overload their brain and have a bloody discharge coming from their ears.

So in the future I will always strive to use the word problem when it relates to a question raised for inquiry or any unsettled question. I will still strive to arrive at a solution to my problem, either by by conducting research (Wikipedia and Google don’t count unless the citation can be documented) or until I gain an understanding of my problem and arrive at a solution. I also may sit down with a group of people to discuss the facts of the problem and strive to arrive at a solution that is agreeable to all.

I will leave the word issues to bloody discharges from a body, when a stamp or stock is released, or when I want to have a never ending discussion about something that is ill defined and has no point. Those are my only issues with this word problem of clarity. When I was in the Navy we called them “Sea Stories.”

So this is my stand against jargon, incorrect language usage and unclear communication. I am tired of my industry skirting around problems by calling them issues, so I am taking a stand with this blog post. Let’s all be honest about our Problems vs. Issues and call a spade a spade! Because you can't solve a problem until you admit there is one.

Who’s with me?

You can leave your comments below or send me an email to blogger@eng-software [dot] com. We really do read every one!

------------------------------------------------------------------------------
Wikipedia is a registered trademark of the Wikimedia Foundation. 

Watching Star Trek and Giving Birth to a Green Book

Estimated Reading Time: 2 minutes 14 seconds. Read Later

This month’s Guest Blogger, Jeff Sines is the Training Lead for Engineered Software, and co-authored the second edition of the Piping System Fundamentals book. Sines brings over 20 years of experience in plant operations, process engineering and over 500 hours training instruction experience.

Ok, I’m not a woman and I don’t really know how it feels to give birth, but I watched my wife deliver my two boys and I remember the look on her face, her complete and utter relief. How she looked then is how I feel now as we wrap up the final touches on the second edition of Piping System Fundamentals: The Complete Guide to Gaining a Clear Picture of Your Piping System, (affectionately known as the “Green Book” here in the office because of the cover).

My first project when I first joined Engineered Software in early 2008 was to read and comment on Ray Hardee’s nearly completed Green Book. I made a few suggestions and some minor edits, but overall it was a good read. It was a great foundation for the 2-day, Piping System Fundamentals course that Ray developed and he and I began teaching later that year. As we conducted over 75 classes with almost 2,000 attendees, the feedback from our customers gave us some great input about the strengths and weaknesses of the course and the companion book. We made changes to our PowerPoint presentations, deleted some material, and added additional topics that enhanced the value of the course.

After so many changes to the course, it was time to come out with the second edition of the Green Book. When Ray tasked me with co-authoring the second edition, I felt like Dr. “Bones” McCoy telling Captain Kirk in Star Trek: “Darn it Ray, I’m an engineer, not a writer!”

Perhaps the most difficult part of this project was learning how to use the InDesign^® software to write the book. Why can’t this program be easy to use like our PIPE-FLO^® software? After learning just the basics to do what I needed the program to do, I was going full steam ahead with the second edition, jumping from InDesign to Microsoft^® Excel^® to Microsoft Visio^® to PIPE-FLO then back to InDesign seamlessly.

Of course the internet was an invaluable resource as well. What better way to explain how a pump works than with a nice cutaway drawing? It’s amazing what you can find on the net nowadays. With permission from numerous companies, the use of their images adds tremendous value to the book. As a note, I would like to thanks all those again who were willing and helpful enough to lend their images to the book and training materials.

Now that the Green Book is on the verge of publication, there’s an urge to kick back, take a breather, and relax. But just like giving birth to a bouncing baby boy, this is only the start of the journey. More projects await me. There is another book to write, a new version of PIPE-FLO to work on, and new products to develop. Beam me up, Scotty!

We are welcoming guest bloggers. Just send us a message if you would be interested in becoming a guest blogger, including your topic or topics you would be interested in covering. Email blogger@eng-software.com. Don't forget to leave a comment below, and tell us what you think.

From ESCAPE to Premium

Estimated Reading Time: 7 minutes 42 seconds. Read Later

In my last post, I discussed the creation of PUMP-FLO and its transition from a DOS application to a Windows application, developed and first released as E.S.C.A.P.E. by the Aurora Pump Company. With the completion of E.S.C.A.P.E., it was time for us to release PUMP-FLO as our MS Windows pump selection program.

The major difference between PUMP-FLO and Aurora's E.S.C.A.P.E. at that time was that PUMP-FLO could select pumps from ANY supporting pump manufacturer’s catalog. E.S.C.A.P.E. could only select pumps from the Aurora product lines. In other words, PUMP-FLO could select any centrifugal pump provided the manufacturer had an electronic pump catalog for use with our program.

After a couple of months of development, we released PUMP-FLO for Windows version 1. Upon the release, we had one pump manufacturer onboard, Aurora (the Aurora catalog ran with both PUMP-FLO and ESCAPE.) Now it was time to get some more manufacturers onboard.

Once again I got out my list of pump manufacturers and sent them all a letter describing how they can use PUMP-FLO as their pump selection program simply by creating and adding an electronic pump catalog. Once again, we were overwhelmed with silence. Crickets.

Since we had firsthand experience with the Aurora sales group, we knew the value PUMP-FLO held for a pump sales team and we would not be stopped. So I decided to start calling the pump manufacturers on my list to tell them the story first hand.

After a couple of months I had over 90 pump manufacturers identified in North America, complete with their company address, markets served, along with their sales manager. I discovered that many of the manufacturers had multiple brands they sold their products under (Original Equipment Manufacturers or OEMs).

Once I got the pump market sorted out I decided it was time to go visit them and sell them on the idea of creating their company’s electronic pump catalog for use with PUMP-FLO. What was really disappointing is that we were offering to create the manufacturers’ pump catalogs for free, and we still didn't have any takers. All a manufacturer had to do was to supply us with their pump curves in paper form, we would create their catalog, and send it for their review and approval.

As an engineer I never had a business class, nor did I know how to sell, but now I was on a mission. I took my 10-pound laptop on the road with me and demonstrated the program to manufactures, pump distributors, to pump buyers at trade shows, in airport waiting rooms and even on a cross-country flight. Based on the positive response I knew that we had a winner, but we still had the problem of getting the manufacturers on board with their electronic pump catalogs.

After 18 months, PUMP-FLO still only had the Aurora catalog available for selection. Getting the manufacturers to commit was much harder than I originally thought. I then had a great idea, we would create mini-catalogs (25 pump curves of our customers choosing) for our PUMP-FLO customers for free. The PUMP-FLO customer would send us a copy of the manufacturer’s paper catalog pages they wanted, we would enter the data, and send them a disk back in the mail that could be used with PUMP-FLO. To make it even more valuable we would merge previous curves from the same manufacturer into the catalog so over time we would have a bigger catalog for the manufacturer.

We did this for about six months and in no time we had a collection of manufacturer’s catalogs. We then started sending out press releases announcing the availability of the each manufacturer’s catalogs. One of the manufacturers found out that we were distributing an electronic pump catalog for their products and had their New York lawyer send us a letter wanting to know how much money we were making so they would know how much to sue us for.

Needless to say we got our lawyer on the case and after spending a week in study he gave us a lawyer opinion. He said there was precedence in favor of what we were doing, and precedence favoring the manufacturer (just what you would expect from a lawyer). I then asked him what he would recommend and after 30 minutes of disclosure, precedence, and hemming and hawing he suggested we write a letter to the manufacturer "Asking for forgiveness and promising to sin no more." I spent the weekend writing a very contrite letter; it must have worked because they said they would drop the suit if we never sent out their pump data ever again.

Finally our luck changed and after two years of trying we finally got our second manufacturer to sign. I wish I could say that it was because of my excellent salesmanship. It turns out I was out of the office when Don Smiley of Weinman Pump called.

Since I was out, Carolyn Popp, (our President & Chief Technical Officer) answered the phone and had a nice talk with him. He said they were really interested in getting added to PUMP-FLO, but they didn't want their pumps listed next to their competitors. She said that was not how the program worked.

She explained that our mutual customers would buy PUMP-FLO from us, and get the Weinman electronic catalog from them. Don then asked how the customer got the electronic catalog. Carolyn explained that we would create their electronic catalog for them from their paper pump curves. Once we create the catalog they would review it, and once approved they would get a master catalog disk that they could freely copy and send out to their customers with PUMP-FLO. She went on to explain that since they sent out their catalog they would know everyone who had their electronic catalog.

The next day Don flew up from Conway, Arkansas and signed the agreement in person. Finally we had our second manufacturer committed. From then on I made sure that the pump manufacturer understood they were in the loop and their electronic pump catalog was their property to give to any PUMP-FLO customer they wished.

A couple of weeks later we got a call from Brian Tims of Paco Pump (then located in Oakland, California). Brian was calling from one of their pump distributor’s office and said he saw one of their pumps selected using PUMP-FLO. He wanted to know what we were doing.

Paco was one of the manufacturers that we had created the “free” customer requested catalogs and had many of their pumps already created. Fearing another unpleasant letter from their lawyer, I let them know we were not doing that anymore. Sensing the fear in my voice, he asked how the program worked. I gave him the discussion about how we worked with them to create their electronic catalog, and once reviewed and approved it was their property for them to distribute. He then asked how long it would take to get their catalog created and I confessed that we had previously created their entire pump catalog because of the initial response from our PUMP-FLO customers. Once again, swearing that we no longer send it out.

He then asked how he could get a copy of PUMP-FLO to all his pump distributors, so I told him it was available for purchase. To sweeten the deal, I mentioned if he bought enough copies of PUMP-FLO we would give him the Paco Electronic Pump Catalog that we created for no additional charge. He asked how many they would need to purchase (I assumed that 100 would be the maximum number we could ever possibly sell to pump company), so I said 50 (may as well go big, right?). He said, "OK, I'll send you a check for 50 and once we get the catalog reviewed and approved we'll send in a bigger order." I was elated!

After that we knew without a doubt, that PUMP-FLO was a winner. Re-doubling my sales efforts, I started visiting every pump manufacturer I could. With all the long plane flights, I decided to read some sales books. Every book suggested listening to your customers to find out how their sales and selection process worked, and ask about their current challenges. So I started listening, and began to learn how pump sales groups wanted to use our program in order to do their job better. This allowed me to focus on their needs and show them the existing PUMP-FLO features that best meet their requirements. This in turn, allowed me to determine what new features we should add in the future. Once I started listening and helping them streamline their internal workflow we started signing up pump manufacturers left and right.

In the mid-1990s, the Internet gained in popularity and wide use. Before you knew it, all anyone was talking about was the paradigm shift (remember that buzz word?) and how the Internet would “CHANGE THE WORLD FOREVER.” Before you knew it everyone I talked to, wanted to know when PUMP-FLO would work on the Internet. We then started examining what it would take to create a Web-based version of PUMP-FLO and based on the requests from the pump manufacturers we decided we needed to make the shift.

This time we partnered with Big Machines, an Internet startup based out of Silicon Valley. We started working together so PUMP-FLO could select the pump, and the Big Machines configuration program could help the pump sales person price the pump. After going to a short training course on developing Internet application we were once again on the bleeding edge of technology. After a few months we had PUMP-FLO running on the Web and started shifting pump manufacturers pump selectors to their own Websites. This allowed the manufacturer to send their customers to their company website and have online pump selection that looked like their own brand.

In early 2002, shortly after the dot com bust, we still had pump manufacturers and end users using the program to help them select and specify pumps for their needs. We had survived the bubble and even began to thrive in the next generation of the Internet, Web 2.0. We continued to develop the programs features both on the Windows and Web versions, and now we have more than 115 pump manufacturers using PUMP-FLO to select pumps for their customers. They are even using PUMP-FLO on their mobile devices now. Here are some interesting statistics about the success of the Web version of PUMP-FLO.

Since we started the PUMP-FLO.com website, we have over 243,700 registered users with an average of 2,000 new registered users per month. Every day, over 1,000 people use PUMP-FLO.com to select a pump for a pumping application.

I don't know if this is a paradigm shift, if pump manufacturers have frictionless commerce, or if we have changed forever the way people buy pumps. I don't think so, but I do know that PUMP-FLO is able to bring pump buyers and sellers together. Using PUMP-FLO, pump buyers are better able to understand how a particular pump will operate in their system. The pump sellers can now explain to the pump buyers why the choice they made was the best one for their application. After all isn't that what business is all about, listening to your customer, and giving them what they need to make their life easier?

Do you have any questions for me? I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. In addition, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks for reading!

PUMP-FLO Beginnings: ESCAPE

Estimated Reading Time: 6 minutes 25 seconds. Read Later

Since we started the countdown to the Engineered Software 30th Anniversary, I have gotten many requests to describe the development of some of our programs. The subject of this blog is a short review of the creation of PUMP-FLO.

It was after an upgrade of our PIPE-FLO / NET-FLO programs (footnote 1) (in DOS) that we started calling our customers, asking how they used the software. The main response was, it helps in calculating the design point needed for centrifugal pump selection. After the 5th or 6th such call we had a good idea that our next program should help in the selection and evaluation of centrifugal pumps.

In 1985, we started program development and in two months, PUMP-FLO was finished and became the fifth in our FLO-SERIES (footnote 2) of piping software. This first version was a DOS program where the user entered the pump performance data, and the program calculated the power requirement and the Net Positive Suction Head available. In addition the impeller diameter and speed could be adjusted and the program calculated the new pump performance data.

There were two problems with that first version preventing wide use of PUMP-FLO: first, it did not display a pump curve, and second the user had to manually enter the pump data. There were provisions in the program so manufacturers could supply their data in electronic pump catalogs for use by the program. We set out working with pump manufacturers to create their electronic pump catalogs; we offered to do it free if they would make the data available. I got a list of 80 centrifugal pump manufacturers sent out mailing to all and got zero takers.

In 1987, I was a panelist at the Society of Plumbing Engineers session discussing the availability of engineering software for piping calculations. Tim Smith, from TACO Pumps was also a panelist, and was demonstrating their new pump selection program. The user entered a design point and the program search through the TACO catalog and presented a list of pumps meeting their needs. It could display the pump curve on an IBM Color Graphics Adapter (CGA), or the Hercules Graphic Card (HGC).

In talking with Tim he said the majority of the development work was writing the device drivers for the two graphics cards, and the Epson MX-80 dot matrix printer. After seeing this I knew PUMP-FLO had to display a pump curve, but we didn't want to have to write device drivers for every new monitor and printer.

In 1988 we were developing an AutoCAD interface to our NET-FLO program and I needed a mouse pointing device. The mouse I purchased was bundled with Microsoft Windows Version 1. After using the mouse with AutoCAD and really enjoyed the ease of use a mouse pointing device for CAD applications.

During that time period Microsoft had a strong marketing push saying program’s written using their Windows environment did not have to write their own device drivers, Windows took care of that for you. I realized that if we made PUMP-FLO a Windows application we could display and print pump curve without the hassle of writing device drivers.

In 1988 we decided to make PUMP-FLO a Windows application, now all we needed was a launch customer. Once again I fired off letters to 80 manufacturers stating what we could do for them, and then waited. This time we got 1 response from Aurora Pumps in North Aurora Illinois. It seemed their sales people were getting asked by their customers when they were going to have a pump selection program like Taco.

We showed them an example of our DOS version of PUMP-FLO; they were interested but said their program needed to display and print the pump curve. I then showed them a mockup of what a Windows based pump selection program would look like (developed using MS Paint) and saying it could support all available graphical displays, printers, plotters, and pointing devices. I was giving them such a sales job I sounded like I was working for Microsoft.

The discussions continued, they sent one of their sales engineers to our office to discuss what the program needed, then asked us for a proposal. We gave them a rather optimistic schedule for delivering the program, and they said we had a deal if we could chop two months off the schedule so the program would be ready for their annual sales meeting in early February.

At the time, we thought the money was good, and in June 1988, we signed the deal. After signing the contract, Carolyn Popp (the other founding principal at Engineered Software), signed up for a two day C programming class, and a three day Windows developers course.

After attending the C class, she said it was just another language and should have no problem picking up the language. The next week she went to the three-day Windows programming class. The instructor was one of the original Windows developers, and many of attendees in the class were Microsoft employees learning how to support and write their application tools. She came back saying Windows was much harder than estimated, and was concerned about our 6 month schedule. Yet, in a couple of weeks, she was able to get her program to compile and display a crude menu, so she felt a little better.

Aurora had approximately 600 individual pump curves that needed to be entered into their electronic catalog. I was the lead on this effort. It took approximately 90 minutes to enter a pump curve into the catalog, and with 600 curves to enter I quickly realized additional help was needed. Enter the interns, we hired two drafting interns from a local technical school and started creating the catalog. While entering the pump curves we streamlined the process and cut the time to 60 minutes per pumps.

To meet our schedule both Carolyn and I were working 12 hour days, 6 days a week, on Sunday we cut our day down to just 8 hours.

By September, the catalog was being built, and the program’s menu structure was established. Carolyn was working on the pump selection engine and displaying the selection list on the screen. Aurora was having a sales manager meeting that month and they wanted us to show what we have accomplished to date and how the program would work.

Carolyn was getting the program together so I could practice my demonstration before heading off to Aurora. I heard a blood-curdling scream coming from her office saying, "The program doesn’t work anymore!" She tried to recreate what she was doing, but she couldn’t get the program working again. By this time, it was after midnight and I needed to get some sleep before my flight to Aurora at 6 later that morning. She stayed at the office and said to stop in the office prior to going to the airport. At 6:00 am the next day I saw a single disk on the desk, a mouse on top of the disk and a note saying “It works. YOU MUST USE THE MOUSE, whatever you do, don’t use the keyboard.”

When I arrived in Chicago, Aurora met me at the airport with a town car and took me to their offices for the demonstration. I had no idea why the program crashed the previous day, I use only the mouse and everything worked OK. Since we had not completed the graphing function of the program they were treated to an MS Paint generated sample graph window. They liked what they saw, then re-enforced the need to meet the schedule because the program was the highlight of their meeting. They then thanked me for coming and I was on my way.

By mid-January 1989 after spending hundreds of additional hours developing and testing the program, and entering and checking their pump performance data we had a working program. At their February 1989 sales meeting, we demonstrated their pump selection program called ESCAPE (Engineer’s Selection & Computer Aided Pump Evaluation).

After demonstrating the program at the keynote meeting, we got a standing ovation. There were plenty of handshakes and back pats to go around and everyone was all smiles.

That afternoon we had to train over 100 sales people on how to use ESCAPE. We had four, one hour familiarization classes with 25 attendees per class. We had everyone go through a pump selection and evaluation and it was amazing how easy they were all able to pick up the program.

When the last class was finished at 4:00 PM, we still had a crowd of 30 to 50 sales people waiting to use the program to select pumps for their customers. Finally, at 6:00 PM we were exhausted and had to lock up the computer room. At the happy hour with an open bar, (after all it was a sales meeting), we were introduced to the President of Aurora Pump. He congratulated us on ESCAPE and thanked us for saving him so much money. Since the program had not yet been released, I ask how we saved them so much money. He said normally the sales people continued their discussions at the open bar, and that year’s bar bill was $10,000 less than previous years because so many of the sales people were using the program.

Once the Aurora ESCAPE program was completed and launched, we started working on our PUMP-FLO program. We started working with other pump manufacturers to create electronic pump catalogs for their products. In the next blog I will be talking about the trials and tribulations of creating pump catalogs for use with PUMP-FLO.

Do you have any questions for me? I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks for reading!

---

Footnotes

1. Prior to the release of our windows version of PIPE-FLO 4, the functionally of our piping simulation software was broken into the PIPE-FLO and NET-FLO programs. The DOS version of PIPE-FLO was used to design single pipelines and save the designed pipelines into a pipeline database. Using NET-FLO our hydraulic network analysis program; people would build a network by connecting the individual pipelines from the pipeline database into a total system complete with pressure sources, pumps, components, controls and demands. The reason this was done was that in the early days of microcomputers (even prior to DOS) programs were limited to 64 kilobytes of both memory and program space.

With the release of Microsoft Windows version 1 with its improved memory management and larger addressable memory we were able to combine PIPE-FLO and NET-FLO into a single program called PIPE-FLO Professional. Back to top

2. Prior to the release of Microsoft Windows, we had separate programs to handle various functions needed for piping system design. We called our group of products The FLO-SERIES. PIPE-FLO was used to design or enter individual pipelines into a pipeline database. All the other programs in the FLO-SERIES could read design information from the pipeline database. Our SYS-FLO program calculated how a system of multiple pipes and pumps in series would operate. Our NET-FLO program was for multiple looped networks.

We also had utility programs that could run as a standalone program or read pipeline design data from the database. This program included ORI-FLO for flow meters, PUMP-FLO, CON-FLO for control valve selection, INS-FLO from calculating insulation thickness and FLO-MANAGER. We marketed these programs as The FLO-SERIES. Back to top

---

Testing 1, 2, 3...

Estimated Reading Time: 5 minutes 26 seconds. Read Later

The Importance of Product Testing

As mentioned in my September blog, Engineered Software will be celebrating 30 years in business in 2012. In that post I listed the core value we have followed to better meet our customer’s needs and expectations, specifically:

1. Create a sustainable company
2. Create product that can be used by a wide variety of people, not just engineers
3. Play well with others.

In this month’s blog I will be sharing with you how our software testing has evolved over the years.

When we started Engineered Software both Carolyn Popp and I (the two founding principles) saw the value of developing a testing program for our software. Our feeling was, if we released a program that had a calculation error, our customers might not trust our new company. In addition, if the customer had trouble entering the necessary data or lost data due to a problem with the program, we were not providing them with the value they expected. For the first version of PIPE-FLO, we developed a series of program features; the formulas the calculations were based on, along with a set of example calculations. These example calculations included a variety of edge cases designed to test the program source code.

I developed a series of test problems from text books, technical publications such as the Crane Technical Paper 410, along with developing a series of calculations performed using an electronic calculator (remember 1982 pre-dated Lotus 123 and Microsoft’s Multi-Plan). A set of calculations sheets were developed complete with the equations, references, all input values, along with intermediate and final calculated results. Prior to every program release, these examples were entered manually into PIPE-FLO and the results validated. Carolyn, a former IBM system engineer, was just as adamant on program testing and validating prior to program release.

Our third & fourth employees, Jaclyn and Kathleen Byron (we often called them J&K), both with mechanical and civil engineering degrees, were hired to improve our program testing, provide customer technical support, and assist in software development. Based on their customer interaction they were able to created test procedures to validate all engineering calculations along with the user interface. They also were responsible for automating the test procedures by developing test scripts for each program feature.

When one of the software developers finished a new PIPE-FLO feature, J&K created an automated test, and checked the results. Any problems with the new feature were brought to the attention of the programmer and resolved. Once we had a PIPE-FLO release candidate, we would perform all automated tests again to validate the software results prior to release. The release testing took approximately 2 – 4 weeks to complete, allowing the correction of last minute program bugs, along with a review of the test results.

As our company grew, we added more programmers and engineers to our development team. In 2006 we decided it was time to update our software development and testing practices by implementing the Agile Software development process.

The major impact was to document the proposed program features and so everyone knows how the feature works. The process starts by engineers creating “stories” for each feature describing how customers used the feature. The application developers would write the program code to meet the requirements listed in the “story”, and the developers in test would develop the testing needed to ensure PIPE-FLO meets the “story” requirements.

Testing is now broken down into unit stages:

• Unit Testing
• Integration Testing

To demonstrate I’ll use an example for calculating the fluid Reynolds number. First engineering first creates a “story” defining the Reynolds number calculation, the data that must be supplied, and a variety of examples with the calculated results.

The application developers create a function for calculating the Reynolds number. The new function is placed in the function library used by all developers that need to calculate the fluid Reynolds number. In addition the developer creates a “unit test” based on the example calculations supplied by engineering in the “story.” The unit test is then placed in the unit test library that is run every time the program is compiled by any developer.

Now let’s say the developer creating the orifice sizing feature needs to calculate the fluid Reynolds number of the orifice. The software developer will use the previously defined Reynolds number function. If the function needs to be modified for the orifice sizing calculations, (say using the orifice diameter instead of the pipe diameter) then the Reynolds number function in the library may be modified by the developer writing the orifice feature. Once a developer compiles the program on their local computer the Reynolds number unit test will be performed to insure nothing was changed that would give bad Reynolds number results for either the pipeline or orifice Reynolds number calculation. If the test fails the developer knows immediately there is a problem in the Reynolds number function and makes the necessary correction.

Once the developer has completed the orifice sizing feature on their computer they check in their code to a central build server. The build server is where all programs are compiled for release. Once the code is checked in on the build server all unit tests are performed on the code, if any problems occur the developer is notified immediately. The build server performs all unit tests each time any one of the application programmers check in their source code.

Integrated Tests are developed by a separate group of programmers that specialize in software testing. The developers in test create the integrated tests to ensure the program’s higher level features work as called out in the “story.” The majority of these tests are developed to test PIPE-FLO’s user interface.

For example in PIPE-FLO the pipeline graph window shows the fluid Reynolds number over a range of flow rates. The developers in test will create an integrated test to check that the graph window is acting as defined in the story. For example the integrated test may check to see that the Reynolds numbers are graphed and displayed and the user also has the ability to change the color.

In the past the integrated testing was conducted when the feature was initially added to the program, and at the completion of the program prior to program release. The time difference between initially adding the feature releasing the program could be measured in months. During that time span a developer may make a change in a new feature that has an effect on a previously tested feature.

With our new automated testing once an integrated test is written to test a feature it is added to the test suite on the testing server. Every night the test server performs all automated tests.

In the evening, the test server takes that day’s program from the build server and loads it to the test server. The test server loads the current program onto multiple computers on the test farm. The test server then assigns the various integrated test to each computer and keeps track of the results. Currently there are about 10 computers in our testing farm and it takes approximately 6 hours to perform the test and review the results.

The next morning each member of the development team can check to see if the code they wrote yesterday has an adverse effect of the program development. If any of the tests fail the developer will be notified and can make the necessary changes that day.

This testing has paid off for both Engineered Software and our customers. In the last two versions of PIPE-FLO we have only had to issue one maintenance release to correct problems associated with the program. A more reliable program means less stress for such important engineering choices, and our aim is to make our customer’s job easier.

I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks for reading!

Thirty Years of Providing a Clear Picture

Estimated Reading Time: 3 minutes 43 seconds. Read Later

I always like to break a process, list, or ideas down into the fewest number of items, three is ideal. I can easily remember three items, but anything more and I need to write it down.

Creating a list is much more difficult that remembering a short list:

• First you must find paper and pencil to create the list.


• Second you must remember where you put the list.

• Third you must refer to your list when making your points.


• Forth well I can’t seem to remember now, but it was important.

You also must think of your intended audience that is receiving your message. For your ideas to be meaningful, they must be remembered. When I listen, by the time someone is on the second point my mind starts wandering. After their forth idea, I find myself wondering where I put my list of items I needed to pick up after work.

The other day I was in a sales and marketing meeting and mentioned that Engineered Software’s 30-year anniversary is April 3^rd 2012. I then asked the group why they thought we were able to make it as a company to this major milestone. They started listing a variety of items, but Dennis Worrell, our sales manager said we need to keep the list to no more than three items so people will remember.

After the intro you probably though that I came up with the idea myself, that’s why I always like to have smart people on my team to help make us look good.

So here is the list of things that we have been doing for the last thirty years to make our company grow:

1. Created a sustainable company


2. Created products that can be used by a wide variety of people, not just for engineers


3. Play well with others

I’ll be expanding on the items in this blog, and will be covering highlights and providing additional details during our upcoming 30th anniversary year.

Create a sustainable company

From the beginning, our goal was to create a company that can grow to best meet the needs of our customers. We listen to our customers and they said they wanted products that are easy to use, reliable, and helped them better understand how their systems worked.

• Make the programs easier to use. We were an early adopter of Microsoft^® Windows^® with our 1989 release of PUMP-FLO™. It ran using the Windows 1 operating environment.


• We have always had a written test plan for our software products. This ensures we have documented acceptance criteria, and the completed software worked as designed.


• In 1987, we got our first request for product training. Over the years, our customers have helped us progress our training offerings to more than just software. Now we have courses on piping system basics, pump operation and maintenance, and improving system profitability.

Created products that are not just for engineers

I am an engineer and couldn’t imagine myself doing anything else. When we started the company, our goal was to provide software tools for engineers. Our first PIPE-FLO^® customers were EPC firms (Engineering, Procurement and Construction).

After a short time, we started selling to owners and operators of piping systems as well. They liked how PIPE-FLO provides them with a clear picture of how their systems were operating, and we liked how they helped us expand our business. Ease of use was high on their list so we strove to make our programs more meaningful to these customers. PIPE-FLO is used to troubleshoot maintenance problems, help operations determine how their plant operates under off-normal conditions, and save the utilities group on energy costs.

In the late 1980s we released PUMP-FLO, our centrifugal pump selection and evaluation program.

Three months after releasing the program, a major pump manufacturer purchased copies for every one of their sales staff. It seems they were using PUMP-FLO to help our PIPE-FLO customers select the best pump for their applications. This leads us to the third key to success, “Play well with others.”

Play well with others

One thing we discovered in the first 30 years of business is that it takes a diverse group of people to run any business. We always strive to learn more about our customer’s workflow and businesses processes. As a result, we discovered that if we could play well with others we were able to offer greater value. As mom always said if you want to play, you need to communicate. Here are a few pioneering examples of how we make our applications play well with others:

• One of the early communication features of Microsoft® Windows was Dynamic Data Exchange or DDE. We incorporated DDE into PUMP-FLO and published our user codes so others could gain access to input data and program results. This allows pump manufacturers to develop and integrate configuration and pricing programs, dimension drawing programs, and document management program seamlessly with our PUMP-FLO.


• Many of our PIPE-FLO customers are hard-core spreadsheet users and asked if PIPE-FLO can send results to their Excel® spreadsheets. We did one better, we made it so PIPE-FLO can provide two-way communications with Excel. Now our customers are writing customized datasheets under Excel and automatically importing design data directly from PIPE-FLO. Others are writing spreadsheets that help them optimize their initial system design.

By developing an easy to use tool that meets the needs of many different groups and allowing our products to play well with others, we have been able to grow and prosper for 30 years.

I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks for reading!

Placing a Wager on the Future

Estimated Reading Time: 5 minutes 8 seconds. Read Later

In my youth I had the privilege of attending the United States Merchant Marine Academy at Kings Point, NY. The Academy trains young men and women for careers in the maritime industry. To graduate you needed one year of sea going experience prior to sitting for and obtaining a US Coast Guard license. The academy sends two cadets out on a US flag merchant ship for one year. During my sea year, not only did I get to see the world, but I also got invaluable experience in engineering, how to work with others and learned time management. It was a great time and I have always considered my sea year a life defining experience. 

Fast-forward 15 years. When we started Engineered Software, we decided that whenever possible we would attempt to hire interns. When we first started out the decision was based on cost, but as time went on we saw it as an excellent opportunity for employee development. Over the years, we have lost count of the total number of interns we have employed but if I were to guess, it would be over 50. 

The first two interns helped enter our first round of pump curves; and they entered over 600 pump curves in four months, for the next 10 years we employed many interns to enter pump performance data. Our next intern was a business student from The Evergreen State College in Olympia, WA. Shortly after he was hired we had a need to teach 120 sales people how to use our PUMP-FLO. Since we needed three people to run the class, we asked our new intern, a college junior if he would like to go to Ft. Lauderdale for a week in January. Needless to say he said yes, did a great job for us and said he had a great time. Not surprisingly after that, for the next two years we had no problem getting the best Evergreen students applying for our internships.
 
Another particularly memorable intern, or should I say two, were degreed mechanical engineers that were going back to school to get a civil engineering degree from St. Martins College in Lacey. These two engineers happened to be identical twins… and did I mention that they were women? I’m guessing this is highly uncommon.

After six months, Jacqueline and Kathleen Byron (we called them J&K around the office) finished their internship and we made them a job offer upon graduation. They accepted and became the second and third engineers of our company. They worked on technical support, developing the engineering program interface, program documentation and software testing. They worked for us for 15 years before starting their own engineering firm.  We have had additional engineering interns over the years that have helped in software validations, development of program help file, and other technical publications.

When we had the need for a marketing intern we went to Pacific Lutheran University in Tacoma WA. Justin Johnson joined us as an intern for 6 months and did a fantastic job developing marketing material, updating our Website, and managing the customer list. Before graduation we made him an offer and he accepted becoming our first Marketing Manager. He continue to do a great job creating press releases, getting articles picked up in technical magazines, and developing an effective direct marketing program. One day he came into my office and wanted to discuss some ideas he had on marketing PUMP-FLO. I asked him to give us a presentation on his ideas. The next day he gave us a presentation outlining a business plan; complete with project cost, revenue projections and a schedule. In his five years with us, he did a great job of building our PUMP-FLO.com product line, and brought in over new 40 pump manufacturers. 

We have had approximately 15 -20 interns in our software development group. They came from a variety of local colleges and universities including St. Martins University, Pacific Lutheran University, University of Puget Sound, The Evergreen State College, University of Seattle, and South Puget Sound Community College. They joined us with solid programming knowledge and unbridled enthusiasm. Each new intern got assigned a project and a mentor and then we let them go to work. Working with their mentor they gain some real world experience working on commercial products. 

Four members of our current programming staff started out as Engineered Software interns. Jeff Trimble from the University of Puget Sound has been with us since 1997, Zack Vawter from St. Martins University has been with us since 2004, Jennifer Dres from South Puget Sound Community College has been with us since 2008, and Heinrich Hoza just graduated last year from St. Martins University. Each has made major contributions to our company both as interns and as full time employees. Many of the new initiatives that we have started in our software development and testing processes are a result of their suggestions and efforts in making it happen.

Now here is why we continue to hire interns. As mentioned earlier, many of the interns we have hired we have brought on-board as full time employees. We look at it as a winning situation for both parties. Our interns get a paying internship and more importantly real life experience that is sometimes difficult to obtain otherwise. And we get to work with the next generation of professionals. We often refer to an internship as an extended job interview.

Not only do the internships help train the students, but they also help train our full time employees on how to hire and manage people. Each intern position goes through the same hiring process as a full time employee. This helps our team gain experience in developing a job description, reviewing the applicants, and conducting the interviews.

You may be wondering what some of our past interns are doing now. Many of them keep in touch, we know that two went on to get their Doctorate degrees, and four of them went on to start their own businesses. Many of the programmers went on to work for Microsoft, the US Government, and other large and small software companies in the Northwest. Of our engineers, many went on to get advanced degrees, work for Boeing, and work for the Naval Shipyard in Bremerton, WA. They all were hard working individuals that were grateful of the opportunity to gain some work experience in our small company. But I would say that we were the big winners because we got to work with some of the best young minds out there that were dedicated in showing us the skills they acquired and what they could accomplish.

Now here is my suggestion for you. If your company doesn’t hire interns see what you can do to start up an internship program. If your company does employ interns, bring one into your group. They bring in a fresh objective, ask lots of questions to keep you thinking, and they are truly interested in doing a good job and gaining real world work experiences. Let me know what advice you can share about getting the most out of your internship programs. What benefits have you or your company gained by having interns. Maybe you have been an intern and had an experience (good or bad) that you’d like to share? I am interested in your stories.

I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks!

Why Some Engineers Prefer Old Slippers

Estimated Reading Time: 4 minutes 25 seconds. Read Later

I have a habit of waking up between 4:30 to 5:00 each morning to read when the house is quiet. Today I was enjoying an article about Flowmeter Selection in Richard W. Miller's, "Flow Measurement Engineering Handbook." He said “… orifices flowmeters continue to account for 80+ percent of installed process plant meters.” He continued on that newer flowmeter designs were starting to be considered but he was amazed at how slowly the newer technology was catching on.

As I was pondering that statement (I can easily ponder before sunrise), I looked down and saw my ratty old slippers. It then hit me like a ton of bricks. “Engineers continue to use what is comfortable, sometimes long after it is practical!” How else could I justify wearing 15 year old slippers when I had three new pair (still in their box complete with gift cards) that my kids had given me on previous birthdays? 

How many times to we do something because, “that’s the way we have always done it?” I know using new technology has its risks, but it also has its rewards.

Taking a Risk on New Technology

Now don’t get me wrong, I like new technology, especially if someone else is paying for it. I really enjoy seeing how other people implement a new technology, particularly the challenges they may encounter along the way and how they overcome them. So often we like to take the safe route because we are familiar with the existing method and don’t want to take unnecessary chances.

But what would happen if Kelly Johnson, head of the Lockheed Martin Skunk Works® (makers of the  U-2 and SR-71 spy planes), Admiral Rickover the father of the US Nuclear Navy, or the NASA engineers getting a man to the moon and back took the easy route. They all took ideas that were the stuff of science fiction just a few years before and converted it to bleeding edge technology, then to cutting edge technology, until it finally trickled down to products we use every day. These engineers had to overcome limitations by employing new methods and technology for their ideas to get off the ground.

I have the good fortune of having very talented engineers and programmers that work hard to provide easy to use and understand products for our customers rather than taking the comfortable, less challenging way out. For example in an earlier version of PIPE-FLO®, one of our customers told us they didn’t like the way our drawing tools worked. After further discussion we came to find out the problem was that, our drawing tools didn’t work like the CAD program he was used to using.

We could have taken the easy way out by saying PIPE-FLO is an analysis program not a drawing program and leave it at that. Instead, our team came to the realization that PIPE-FLO may be an analysis program, but our customers use our drawing tools to create their flow diagrams and they wanted the drawing features to operate more like their CAD program. In the next release, we overhauled the drawing tools to work like the drawing tools of the CAD programs. This involved a sizable bit of the programming to update the code behind the PIPE-FLO software but the customer had spoken. Problem solved.

A Challenge Extended

I would like to pose a challenge to all of you reading my blog. Take one of your particularly difficult problems (now I know the PC police say we’re to call them issues and not problems) and figure out how to solve it.  It can be something as simple as determining why a given pump’s mechanical seal continues to fail every six months, or find out the true operating cost of a differential pressure flowmeter and see what new technology is available. You identify the problem, arrive at a solution and sell your solution to your team. It won’t be easy, after all, you’ll have to convince others that your idea is better than the way it is currently done, but it will be enjoyable, and who knows maybe they will even use your idea.

Actual slippers -
No editing was performed.

After my mornings ponder, I sat down at the computer and wrote out this blog article in a single sitting. I was so excited I went to my closet, picked out one of the slipper boxes and put on a brand new pair of slippers. Guess what, they felt great and looked much nicer. I then took the old slippers and put them away, after all, I couldn’t throw them out. Who knows when I may need a pair of comfortable slippers.

Now it’s time to hear from you. What do you think are the biggest concerns or obstacles to using new technology in plant maintenance and design? Do you think it’s the cost, or is there some other reason? Moreover, what problems have you overcome, and what new technology have you employed to solve that problem?

Please feel free to share your experiences, or opinions on this blog entry or any other subject that is of interest. Leave a comment below or email me. I can be reached at blogger@eng-software.com.