Avoid Navision spaghetti solutions!

I’m currently working on a project where my customer have asked me fix some problems with their Navision after they have given up to work with their existing partner. And that would have been a very easy job had it only been a standard Navision. But the customer has purchased a very big add-on which is the foundation of the customer.

Normally this would not through me off. And neither will it, but I sure understand why the partner, who is also the developer of the add-on, did not finish up the last deliveries.

A spaghetti solution!

This add-on is a great example of a spaghetti solution. A solution where code has been added line by line over many years.

On the top this is a very well featured add-on that solves most issues in it’s not too little horizontal area. In fact a very admirable solution.

But then you start looking a little closer then you will very soon see the problems. The solution is not very easy to use. And it’s surely not logically designed. When you then looks at the code, then the first thing that meets you is over 200 tables, even more forms and 64 code units! All in all a very big add-on.

It’s a very typical example of a solution where the customer(s) clearly has take the control from the developer.

It’s also a very typical Navision add-on. You all know them. You created this great solution to one customer in a special industry. And why not start sell this solution to other customers in the same industry? And the additional functionality requested and paid for my the second customer just goes into the solution, when it’s sold to the next customer, and so on. After 4-5 sales (or before) then the partner decides to turn their solution into a “real” add-on.

But at this time, then most partners have already lost. Even with a very strict development management then it’s almost impossible to avoid that it’s becoming a spaghetti solution.

So what is the problem with this spaghetti solution?

Just imagine a bowl of spaghetti. All the spaghettis are mixed into each other. Whenever you pull one spaghetti then you’ll also pull other spaghettis and so on. It’s almost impossible to touch just one, without touching the others.

If this instead is a computer program, a Navision solution, then all the spaghettis are code and objects, all wired into each other. Whenever you trying to pull one error, change one line of code, then it might be mixed with other lines of code. So fixing one error, might give you a new and different error.

When you need to add new functions then because it’s all spaghetti, then it’s impossible for you to see the bottom of the bowl. So instead of doing it the right way, then you have to create a new function on the top where you can see it. The solution has become too complex for anyone to understand it all.

Why does it get this bad?

With my customers solution it’s very clear from looking at their partners reference list why the add-on has become the way it is. The solution started out it’s “life” as a customer specific solution. With each new customer the solution got new functions and features. Some of these features pointing the solution into a different direction. The developer is now faced with two options. Either he can go back and redesign his original solution, so that it will fit both directions. But if he’s doing this, then he also needs to make sure that the customers who already have the solution can still upgrade. He can also design a solution which doesn’t affect the existing customers. A change with is more stand alone. But often more important it’s must faster and therefore cheaper to do. And since it’s his customer who must pay, then what do you think it’s going to be? The right redesign solution or the cheaper solution?

How to avoid that your add-on is becoming a spaghetti solution?

The first problem is typically that the partner just think that he can turn a great customer solution into an add-on. You can’t!

What you can do is to create your add-on based upon and inspired by the initial customer solution. But you should never do it before you have consulted with at least 2-3 other customers in the same industry as your add-on. To create the add-on you basically need to do multiple full scale needs assessments. It’s not enough that you hire one expert who comes from one customer. You need to know the differences between the companies in the industry.

Then you need to create your design. And even if you’re not planning to program everything for the first version, then you should design it all now. Only this way you can prepare your solution for the upcoming changes. The keyword here is really that your design need to be big enough to allow for the unexpected.

The final and most important thing is that you have to stay in control. You need a strong development manager and QA control. If you start allowing customer modifications to be included into the add-on without a plan, then you are already starting to cook your spaghetti. Have a release plan and schedule – and stick to it!

What to do when your solution is already spaghetti?

When I was working with my customer and their spaghetti add-on solution then my first wish was really just start fix all the badly programmed code and start to clean it up.But that’s not really the solution and definitely not my job – at least my customer would pay not me for doing it.

As soon as you have more than 3-5 customers then the problem is that if you’re changing the table structure dramatically (as my customers add-on need), then it will be a very big job to upgrade. Most of your documentation and training material also has to be rewritten.

Redesigning a solution like my customers, would take me at least 400 hours, more likely 600 hours. And who should pay that?

But actually Microsoft Dynamics NAV version 2009 is a good excuse to do it. The upgrade is going to be rather big anyway, so if a redesign can make them “only” need 150 or less tables and forms, then they also have less to upgrade, less to transform to pages. And most important less to maintain in the future.

A simpler code means less errors. Less errors means happier customers. Happier customers means more money!

 

Go ahead let’s see great Navision solutions and less spaghetti solutions!

Comment List
  • Having taken a one-customer project and converted it to a product years ago I agree with you completely.  One tool I have used to prevent spaghetti code has been source code controls like Visual Source Safe.  Is there any equivalent to this with NAV development?

  • Eric - I've also seen a lot of these. One of the extremes was a project where I've done an audit, and found 3000+ extra objects! There were more than 700 new tables, and out of standard NAV only 200 tables were used. You can imagine - there was no consistent documentation, and more than 75% of the solution wasn't documented at all. The customer wanted to upgrade this to NAV 5.0, and I just advised them not to do that, but instead to really invest some time into making a catalog of functionality they use, then to analyze the code and migrate that functionality, while trying to replace that with standard NAV. Any upgrade of this behemoth would just cost equally as much, and deliver little long-term value to the customer.

  • I agree with you, Erik, about badly designed add-ons, but it looks like your spaghetti are overcooked! ;-)

Related
Recommended