Experience Summary

Our staff has years of experience in a variety of industries and with a variety of technologies. Note our brief employee biographies below.

Eric W. Carman

President

I had been working at Electronic Data Systems (EDS) for 11 years when I started this company in 1996. I was starting to explore different opportunities and even different careers when a friend of mine called to discuss a project he was beginning. His intent was just to feel me out and see if I had any interest in it. He was going on vacation for the week and would check back with me when he returned. By the time he had returned, I had the incorporating process well under way and was beginning the job of setting up business. This was just a three month contract, but I had been looking for something else to do, something different - not just the same work for a different company. I wanted more than just a change of cubicle decor.

This was probably not the best of times to start a new business as my wife was ill and scheduled for surgery and I had two small children at home, but I reasoned (rationalized?) that there never would be a "best time" and chose to take the risk. I have to say that this is one of the best decisions I could have made. That contract was extended, in various forms, for almost 13 years. I believe that this is a testament to the mutual respect my client and I shared for each other and the value they placed on my services and abilities.

Over the years, I've worked with both large and small clients and with a variety of tools in a number of different industries. Below, I'd like to sum up some of those experiences to help give you an appreciation of my capabilities.

Financial Collection and Consolidation

The contract that I mention above was with one of the divisions of a large multi-national pharmacuetical company. Our task was to build and support an integrated financial and product collection and consolidation system. The goal of the application was to collect product activity (sales, etc.) and financial activity for the various companies that operated around the world. This data was then combined (accounting for currency translations) at the headquarters level and consolidated.

For those without an accounting background, consolidation is the process whereby all inter-company transactions are removed to properly reflect the overall operations. Additionally, the system took into account the product chain - the path a product took through manufacture to eventual third party sale. When these activities spanned multiple organizations, all inter-company markups needed to be accounted for.

The application was developed for the Windows OS (originally Windows 3.1) with Delphi® and interfaced with the Informix®, Oracle®, and Interbase® databases. There were three of us working on the initial development and we finished the application in less than six months. We began in July of 1996 and the application was deployed and collecting data for the January 1997 actual reporting period. Ultimately the application was used in 4 different divisions supporting over 100 affiliate companies worldwide and was supported exclusively by EC Software Consulting.

This project provided me with a lot of other great opportunities as well. I was asked to travel frequently to Europe and Asia to train the users on the application, to provide support, and gather requirements for new projects. I also represented this client as a subject matter expert based on the years of experience I had working on these applications.

Integrated Scheduling Project

I worked on this project in the early 1990’s at EDS. This system was developed for a large manufacturing client. The ultimate goal of this system was to determine the parts needed to build their product and to schedule, not just the part’s arrival at the plant, but the time they would need to be put onto the supplier’s truck in order to get there.

My work on this project was concentrated in the areas of order and part “explosion”. We were given a series of specifications and a list of orders (usually a 20 week projection) and had to determine all of the parts that were needed to build those orders. The part explosion was accomplished by “compiling” the specifications into MVS/XA machine code and then subsequently running it (on-the-fly as it were) using the order projections as data. The output was a list of all parts needed for each order – each part being represented by a single bit in a long chain of bit strings. In fact, in order to test our work I developed a utility to disassemble the generated machine code.

This system was eventually rolled out to all North American manufacturing plants replacing a number of other systems and consolidating the support and maintenance functions for our client. Additionally, the accuracy of the system allowed them to pursue more advantageous arrangements with their suppliers as they were less likely to modify the part orders due to inconsistencies generated by multiple independent systems.

Database Administration

While I'm not a formally trained DBA, I've done a lot of database administration tasks over the years. I've designed the databases for several applications, installed and maintained Informix and Oracle databases (test and production servers), and performed database optimization when needed. As a result, I like to think of myself as a DBA-light.

My first foray into database administration was while I was working for EDS. I was on an account that was developing an application to handle asset depreciation, deferred taxes, accruals and FAS 109 requirements for companies in the utility industry. My responsibilities included developing the data model, requirements gathering, and performing the role of the Oracle DBA (V.7) for the development arena.

I had worked with databases, including IMS DB, DB2, and Oracle, for the most of the 10 years prior to that, but from a developer perspective. Now I was thrown in as the DBA in addition to the other duties mentioned - sans training. So off to a local bookstore I went. The first week or so, I was balancing the data modeling and requirements gathering tasks with learning what to do with Oracle. After a couple of false starts, I got the database up and running before development commenced and kept it up-to-date as the requirements and data model evolved.

The best compliment I received from this project came from one of my co-workers as the project neared completion. They mentioned that their development was never impacted by any database issues - they never had to wait on the database to be ready.

In a somewhat surprising turn of events, another project being developed within this group asked me to take a look at their Oracle installation and help them to identify and address some performance issues, which I did. Their confidence in my abilities makes this a close second to the above compliment.

When working with databases, I enjoy using tools such as ErWin®, Embarcadero's ER/Studio®, and Quest's Toad®. These are excellent tools and really let the developer focus on the job of developing.

Performance Improvement

Performance improvement can be one of the most interesting (fun?) and, at the same time, frustrating tasks one can do. It is something I am fortunate enough to have had a great deal of experience with. Admittedly, it is one of my favorites. The performance and productivity improvements I've made for clients have led to considerable savings and forestalled the additional purchases of hardware to handle their processing requirements.

Back in my mainframe days, we had access to a profiling tool (whose name I've forgotten) and some of the languages we worked with (i.e. PL1) would show you listings of the assembly generated by the compiler. Most people either didn't know about these tools or couldn't be bothered. I loved them. I learned more from seeing how the compiler built out my PL1 than most other things.

For most people, performance tuning was something you did if you had time - and, of course, no one had time with a myriad of arbitrary deadlines looming. I believe that performance needs to be built in from the beginning - or at a minimum, it needs to be planned for. After all, the solutions to a performance problem generally fall into the following categories:

You need to optimize your current algorithm -or-

You need a new algorithm.

The last option will be a little hard to justify if you've already used all of your time to develop the inefficient one.

I made it a matter of course that all of my code was profiled before I presented it for walk-through. I wanted to know what was going to happen before it hit production. Little things like this make a huge difference.

Case in point: We had a very critical batch cycle for our (EDS's - early 1990's) customer and the cycle was taking all of the allotted time - if nothing went wrong. We were, of course, working on other projects in this application, but we had some leeway to experiment on our own. I took the opportunity to profile a couple of these programs and found several areas that just shot to the top in the list in terms of run-time and cpu usage. As is often the case, the bottlenecks were in what would otherwise seem to be innocuous code. The changes made as a result of this investigation, saved a couple of hours a night and, consequently, saved our client tens of thousands of dollars a year.

Everyone wins.

Life Cycles

I've guided projects through all phases of the application life cycle from requirements gathering to long-term support. In my experience, I must say that I prefer to get involved in the beginning of a project. The requirements gathering process is the best way to get inside the heads of your clients and try to determine what they really need and help to guide them to a useful solution.

The following are just a few thoughts I've accumulated over the years that help me maintain my perspective on a day-to-day basis.

The only methodology that has survived the test of time is the KISS methodology.

Never give your client a blank sheet of paper.

A real data modeling tool is essential - sorry, not Visio®.

A text based event-response list is as complicated as you need to get in most cases.

If you spend more time managing the tools that you use to collect your requirements than actually collecting them, you are doing something wrong.

What am I doing now?

As usual, I am trying to learn new things. I've been studying new languages and operating systems and as you probably noted on the main page of this website, I have been developing applications for Google’s Android™ operating system. This has been a lot of fun and I've had to learn (and un-learn) a lot of new things.

Additionally, I've started examining PHP scripting. As the CMS used for this website is Drupal™ which is written in PHP, I thought it might be useful. Who knows, maybe I'll try my hand at a new module.