Spaghetti Code vs. Structured Code

What is spaghetti code? We have all heard the term spaghetti code, but most of us don’t know what spaghetti code is or why it is a problem. To those of us who are lab managers and/or quality managers (i.e. non-programmers) when we look at procedure, it looks a lot like reading a foreign language.

So we send our top technician to a one week programming class and then turn him loose, thinking he has all the training he needs to increase our lab’s productivity. And for the first few months things looks promising–we get one, then another, and yet another working procedure from our newly found programmer/technician.

But after a while, we start to see a diminishing return on our investment. As the complexity and size of the procedure increases, it takes longer and longer to get a working procedure. When complexities arise, such as flexibility in standards, options and differing specifications based on serial prefix breaks, our new programmer is suddenly spending more time maintaining complex procedures than writing new ones. Productivity slows and we still have product that needs to get calibrated and out the door.

Often the problem is in how the procedures were developed. If we were to look at a typical procedure written in MET/CAL® we would see that the code is hard to follow (see Spaghetti Sample). As you can see, the procedure continually jumps from one location to another. This makes the procedure hard to follow, because the more jumps and nested If statements there are in the procedure, the harder it is to read and debug. This is why inexperienced programmers spend countless hours working on a procedure instead of getting product out the door.

 

So what is the solution? The solution is a structured approach to procedure development. If you develop procedures in-house, your developer needs structure. They need defined programming standards and a set of tools they can use to solve common problems. This allows developers to produce more working procedures with less code.

Every line of code they write is a line of code they have to debug and support. Less code means fewer mistakes, less support, and less rework.

Here at Cal Lab Solutions, we’ve worked hard to create a programming standard that doesn’t look like a bowl of pasta. Our procedures are easy to follow and easy to understand, even for non-programmers (see Structured Sample). We have developed a set of tools that allow our developers to write robust procedures with fewer errors.

Many of our customers have seen the advantages of outsourcing nearly 100% of their procedure development. They’ve run the cost benefit analysis and discovered that their labs are more productive when their technicians focus on getting product out the door.

To learn more about our software products, contact: sales@callabsolutions.com or call: 303-317-6670 (MST).