Managed vs Un-Managed Code

I recently had a customer who was interested in the development environment and platform used for the development of the solution I was presenting. The question was simply this: Is thus product developed in managed or un-managed code (sometimes referred to as native code). At the time, I had to park the question with a commitment to come back to the customer at a later date. I didn’t really know the difference between the two, more importantly, I didn’t understand the motivation behind the question.

To understand the differences, I decided to take a cursory look at Microsoft’s C# language(an example of managed code, pronounced C Sharp) and also revised some of my old C++ (example of unmanaged/native- mostly) books. Using Visual Studio from Microsoft it’s possible to create applications in both languages. To see C# in action, I created a small app to read and manipulate some local windows registry settings.

To summarize, managed code (like C# and Java) is generally executed through some kind of management framework and not directly on the operating system. This may be a Java Virtual Machine or the CLR (Command Line Runtime in the Microsoft .net environment).  The framework provides a protective shell which will manage memory and other hardware resources, so the code never has to deal with accessing those resources directly.  This makes it much more difficult for the application code to perform an action which will compromise the system.  It also makes the code portable.  The code will run anywhere where the framework can run.  To achieve this the source code is sort of, partially, complied into an intermediate langauge that can be understood by  and fully compiled by the framework at run-time. This is referred to JIT compiling (Just-In-Time)

Un-managed code runs directly on the OS.  It can manage memory and other hardware directly. It is compiled for the specific processor on which it runs. Bypassing the aforementioned frameworks and working directly with the operating system gives a major boost in power and performance. The same can not be achieved with managed code, but this also sacrifices portability.

This really gives us a clear distinction between the two one representing performance and the other portability. Their are other issues to consider such as the ease of development. Managed code is often easier to learn, produce and understand. From a customer’s perspective they are probably less concerned about how easy something was to produce and more concerned that it performs it’s function correctly.

So, in summary, if a customer asks this question it is likely that they have some requirement regarding either performance or portability.  In high-performance mission critical applications they are likely to have an expectation that the code will be un-managed. In a disparate, multi-platform environment, portability may be there hot spot.

If you would like to learn more about C#, I’d recommend the following book: Rob Miles’ C# Yellow Book – It gives an excellent overview.

If you believe, like many, that using c# managed code ties you to the windows platform you should check out the Mono VES project, an open source project promoting cross-platform .net development capability.

The Importance of Hands On Technical Experience

To operate effectively in a pre-sales role detailed product knowledge is a must.  You can not truly understand how a product works and it’s functionality without having some experience of it working on a real system.  At the very least installing a demo or test environment will bring you closer to the capabilities of a product, but where possible get involved in  real implementations, in real customer environments.  Occasional secondments to the service delivery arm of your organisation can give you the opportunity to build some real world experience which can be applied to your current and future customer opportunities.

Cogs

Practical experience is particularly useful in environments where you are working with multiple products and multiple product components. Understanding the underlying requirements of each component and how they will integrate with the other components can be of vital importance when proposing a solution.  You may find that two of your components have conflicting requirements and simply can not fit together in the configuration you have designed.  It is better to understand as much as possible about these dependencies early in the sales cycle as these can become show stopping issues which may become critical at the later stages of a sale.

Simple advice on this would be read the manuals, install your virtual machines, install the products, configure the products and run through some mock scenarios.

What is Three Dimensional Pre-Sales?

Introducing Pre-Sales

Depending on the organisation or industry you work in, pre-sales can mean very different things. The main perspectives people hold when categorizing pre-sales as a role are generally polarized at opposing ends of a linear spectrum.  At one end we have technical activity and at the other we have commercial.  The technical-to-commercial spectrum is widely used as a frame of reference.  Some organisations expect their pre-sales employees to be very technical with an ability to dig deep into code where necessary and others don’t require any hands on experience at all. In reality, the definition of the role is flexible and the expectation is that a pre-sales resource will fall somewhere in between.

The linear spectrum of pre-sales activity.

 My loose definition of Pre-Sales: Pre-sales provides the medium to bridge the gap that exists between a customer’s business needs and the functional capabilities of the products and solutions provided a supplier organisation.

Continue reading