What’s wrong with Virtual Machines?

Nothing; you should be using Virtual Machines such as VMWare, they are especially useful for testing and demos but should not be used for development. When developing they are not a good idea. From a practical standpoint you need all the power of the machine and the VM will often use much of the machine’s resources so the VM can be a hinderance. In any case learning how to install is an important part of learning the basic building blocks of Windchill. If a developer can’t install the system, how can they be expected to program it correctly? Finally and much more importantly VMs are often a poor solution to a much deeper and serious problem.
Often the extensive use of VMs is because the custom code and configuration are so difficult to install that it is deemed too complex for a humble developer. This is wrong; the answer to this problem is to make the install of the custom code easy, not to work around it with VMs, but to do this we need a better understanding of some deeper issues

Design a Windchill system with the same ideas we use in product design

The problem is exactly the same as the product design ones; Form, Fit and Function. We should think of our systems as consisting of components or parts and therefore we need to manage coupling and cohesion, not after the event but as we develop our systems.This is not just an abstract concept, it is a very easy to understand and is vital for us to make effective, high quality and maintainable systems. Just like parts or documents, the component parts of our systems have lifecycles, they must be designed to be live and eventually die.

“We have components, we have Java packages”

No, this is not good enough! The design intent is good, but in practice over time even the best designed packges become interconnected like spagetti. The only way we can be sure we are design true components is that they must:

  • Be independently buildable
  • Be indepently installed

Let’s take an example. We have some functional elements we need to provide to our end user; some utilities to listen for part changes, a PDF document processor and a simple interface to extract files. These are clearly separate and should be developed separately but in most cases these are delivered and developed as a single blob of code. Why?

Confusing custom features and configuration

Most clients have large configurations; lifecycles, workflows, resource bundles etc. A developer is obliged to install all this to develop even a small code utility. Again the answer is often VMs. We believe this is wrong, the problem is with the code, it should be adaptable and so we should not need an exact configuration. We should be able to develop it with some configurable options, a small test data set and some junit tests. This is very important for us to create good quality code; otherwise setting up tests becomes to complex and very soon gets “forgotten”.

How to make the separation?

The first point is to make the configuration separate from all code. The configuration is a component and should be managed separately. Then each component is developed separately, but we may need a common library component to share code e.g. Custom Java, Info*Engine Task etc. This means we develop our code in a stack and so each developer only needs to know their component and what libraries it depends on.

Looking at the example it is easy to imagine the stack; note the configuration is on the side, the components are configurable using properties to setup which softtype, states etc they need they do not depend on the configuration.

Retiring code

Nobody when they start a project wants to think of its end, but we must do that. If we have true separation then it is easy, we just don’t install it and “park” the code. Without true separation then we can never unpick it from everything else, it often just sits there. The result is that our code grows and grows and become increasingly complex to install and costly to maintain.


So we need to make our code into components, with a quick simple build process and simple ways to install our components; this enables us to do this and free ourselves from Virtual Machines and the nightmare of mega installations.

Related articles

How to install PDMLink™/ProjectLink™ for developers