The Serenity Of Knowing What You Are Doing

Many entrepreneurs are nervous about how to make offshore outsourcing work for them. How much direction must be provided to offshore engineers to get satisfactory results? A key ingredient is a specification that defines what those results are. You should not have to specify everything in complete detail. A good engineer is creative and can innovate to achieve your goals. You need to outsource to good engineers.

My brother is a good engineer. He knew from an early age that he wanted to be an Electrical Engineer. I think he was twelve when he passed the test to receive a General Class amateur radio license.

As a young kid, I used to watch him build all kinds of electrical gear in his bedroom. It was a good sized room and half of it was dedicated to his radio “shack” on one side and a large workbench on the other. Those were in the days of Sputnik when transistors were new and expensive. Radios were built with vacuum tubes.

You could get a more tangible feel for electronics then by actually holding the tubes, resistors, capacitors and inductors in your hand. My brother’s radios were massive by today’s standards. They had tangible substance and weight.

My brother was my mentor and inspired me to become an engineer too. He went on to earn a BSEE at college and a first job at RCA Laboratories. One day he came home with a story.

He had an co-worker that was NOT a good engineer. I don’t remember the details, but apparently this guy was always making mistakes and just not grasping the purpose of this particular project they were on.

My brother told us, his boss finally had enough. “Look!”, the boss told the other guy, “Do you know what an an engineer is? An engineer is a person that knows what the f*#$ he is doing! Now do you know what the f*#$ you are doing!?”

Wow, what a thing to say! What impact! I was an impressionable pre-teen at the time. I wanted to be an engineer just like my big brother. But now I had this new challenge. If I wanted to be an engineer, I had to know what the f*#$ I was doing! Wow. That was more than I was bargaining for.

Of course, as I grew older, earned my BSCS degree and began my own career, I learned it was more than most engineers bargain for. But it also exposed a major conflict between the desire to have a well thought out plan, and the innovative and creative side of engineering work. If you ever struggled with a writing (or programming) assignment in school, you know it is difficult to plan the creative process.

It reminds me of the Serenity Prayer :

God grant me the serenity to accept
the things I cannot change;
The courage to change the things I can;
and wisdom to know the difference.

Or in other words,

Let me have the wisdom to plan the things I understand;
and let my muses be available when creativity and innovation is needed.

Starting a company requires multiple creative innovations. Some innovations set new goals and some innovations come about in the process of achieving a goal. Here are some examples of innovations from my startups:

The original product idea
Finding a unique source of funding
Discovering a new marketing approach
Reducing manufacturing costs below competitors
You cannot really plan these innovations. They just happen spontaneously and often serve as the main inspiration for the company itself.

People think innovation cannot be outsourced. However, I have seen offshore teams innovate as required to achieve a goal. A good offshore team is not a bunch of programmers thrown together in a room, working on the cheap in some exotic foreign country. They are professional engineers who know what they are doing.

A reasonable specification enables offshore innovation. Whether you are using offshore outsourcing or not, you should take the time to complete a concise product specification. It should sketch out the user interface, describe the major product use cases and define the information objects required in your product.

Consider using the Unified Modeling Language ( UML ) to specify your system. Some developers think UML is overly formal for many situations. But consider it a set of tools to use as needed to describe your product.

UML defines twelve types of diagrams, divided into three categories. You can pick and choose which diagrams best describe your product:

Structural Diagrams include the Class Diagram, Object Diagram, Component Diagram, and Deployment Diagram.
Behavior Diagrams include the Use Case Diagram, Sequence Diagram, Activity Diagram, Collaboration Diagram, and State chart Diagram.
Model Management Diagrams include Packages, Subsystems, and Models.
The structural diagrams define a static view of your product, containing the types of entities and their relationships that do not change as the product is used. For example, orders will always contain line items that will contain part numbers in an order processing system.

Dynamic behavior of your product is captured by one or more UML behavior diagrams. I find Use Cases and State charts to be the most useful. A use case is a sequence of steps users carry out to complete a task with your product. For example, there can be a use case to create an order and another use case to approve it. A state diagram can show how orders change state as they are processed in the product.

Here is another way to think of use cases. The most important use cases, the ones that provide the most value, are the sequence of steps you usually show in your product demo.

Your specification drives multiple processes. Of course it is used to lead the software development effort. A specification is a good way for new employees to ramp up to productivity. In addition, the specification becomes the raw material to begin the product QA process and can be edited to create your product test plans. Finally, the specification becomes the starting point for end-user documentation such as on-line product help and manuals.

Many engineers and managers avoid writing specifications. They either don’t know how to write them, or do not want to “limit their creativity” during the development process. But writing a specification IS a creative process. It should capture and describe in clear language, rather than source code, the innovation your product offers.

Without a specification, you lose in two ways. First, you deprive your engineers (and also your customers and investors) of a full description of how your product is an innovation. Second, you hamper the innovations that are naturally created by good engineers while striving to achieve your product development goals defined in the specification. Investing a small amount of time to create a specification really pays off in improving communication and reducing your risk of failure

Vision Resources

Are you wondering how you will select an expert offshore team to develop your software?

Use the Accelerance outsourced vendor selection service and cut the time of your vendor selection process by as much as 90%.

Accelerance, Inc. delivers impartial & expert strategies and services
for risk-free outsourcing of your software development.