It's no accident that professional construction workers use power tools extensively and so should you. We believe in asking "could this job be done more efficiently with another language, vendor or operating system?"

Unlike other consultants, we are not going to sugar-coat anything. If you have chosen to employ or receive training on a particular product, programming language or operating system, we believe we owe it to you to identify both the perils and merits of that choice. And we will also identify alternative approaches.

Alternatives will help give you the big picture and provide backup strategies. They also help you understand if you are trying to accomplish something the inventors of the technology never anticipated -- a precarious place to be.

Hidden perils will cost you more money than the merits will save you! Typically it's never a problem to learn about the merits:  everyone loves to tell you about the merits! No one will tell you about those nasty gotcha's that devour entire projects -- except SIGNITEK!

This is a radical approach -- but wrong decisions are costly to your organization. What the vendor (or any other proponent) does not say is always more important than what they say.

Things should be made as simple as possible, but not any simpler. Albert Einstein (1879-1955)

For every problem, there is one solution which is simple, neat and wrong. Henry Louis Mencken (1880-1956)

Always get the big picture!

Experienced C++ programmers know the perils of shallow copies! 

(They make your program crash and are generally caused by missing copy constructors or missing overloaded assignment operators, which, unfortunately, are not trivial.)

Experienced Win32 programmers know the perils of leaking global memory.

(They make your computer hang.)

Unfortunately, avoiding these problems may not be simple. At SIGNITEK we believe in giving you the information necessary to avoid the problems down the road. 

Understanding concepts doesn't just mean only identifying perils and merits. 

Long Term Investments

Prototyping has its place.

Long term customer relations.

Re-using what? Everything we can get our hands on! 

Marketing, analysis, design, code within a project, code cannibalized from other projects.

Proactively maximizing re-use does not mean you scoured your company and the entire internet looking for fragments of code to use!  This is a very reactive approach.

Proactive re-use means anticipating re-use -- a definite long term investment. Anticipating re-use means your analyses, designs, implementations and testing are minimally impacted by change. 

Proactive reuse also means maximizing your use of well design libraries. Sometimes we call this class user programming although the concept applies to analysis and design as well.

Proactive re-use is all about minimizing negative impacts (which impair our ability to re-use our efforts).

A proactive approach towards maximizing re-use is making the long term investment to create analyses, designs, implementations and test strategies that are minimally impacted by defects, scope creep, changing problem specifications, changing vendor specifications, changing operating system vendors and changing database vendors (to name just a few things that could change -- the list goes on!).

So we constantly ask ourselves: can these analyses and designs withstand the punishment of

Changing from C++ to Java (for example)

Changing database vendors from Microsoft to Oracle (for example)

A defect in another module you did not write

Late breaking (or changing) customer requirement

Changing graphical user interface technology

Testing is an ongoing process that begins with the analysis model and never ends.

Yes -- testing is an extremely expensive process. But so are undetected defects.

The concept is simple. There are two kinds of programming: Class user programming means using someone else's classes. Class provider programming means creating classes for others to use. (Notice we preclude the possibility of creating classes that no one else uses).

In a perfect world this would be an extremely simple question: Is it more productive to use other people's classes or write your own?

Creating your own classes, modules, packages or subsystems seriously degrades your productivity. This is especially true in the implementation: class provider programming is the hardest kind of programming there is! So how do you recoup your lost productivity when class provider programming is unavoidable? Answer: Class user programming!

In other words, class provider programming is still productive if (and only if) you can find an audience that uses your code. If your name is Alexandar Stepanov (the author of what has since become the C++ standard library), you have already achieved truly large scale re-use. Most of will never achieve re-use at this large scale. A few of us may achieve small scale re-use where a few of our colleagues will re-use our code. All-in-all, class provider programming is a tough proposition: it's tough, slow work (that must be thoroughly documented) and it's usually even tougher to get other people to re- use our designs and implementations.

A much easier approach is to maximize the amount you use other people's classes. Since this is not a perfect world, some discrimination is appropriate here. Not all the free class libraries on the internet are high quality quality and sometimes we cannot avoid class provider programming.

If there is no re-use, there is no object-orientation! 

If you are a class provider, your classes are not object-oriented until someone else benefits from re-using them.