I’ve been asked time and again how CAST is different from performance engineering. And here’s my answer: The CAST discipline of software analysis and measurement versus performance engineering couldn’t be more different. And I’ll explain why and how in a moment. But along with that, it should be noted that they also are like peanut butter and chocolate -- they can go very well together.
Here’s the high level explanation, which I’ll drill into further for those of you who like details. Fundamentally, when you’re dealing with CAST, you’re improving code quality during the engineering phase and throughout the development of the product. CAST technology is used as the code is built, and even after you’ve done performance engineering.
Performance engineering, on the other hand, is just one phase late in the game, when the product is essentially considered complete and you’re doing a final round of outcome-driven optimization. Consider performance engineering as fine tuning the finished system to reach specific response time objectives, while CAST is part and parcel of the software engineering process.
Using dynamic analysis and load testing, performance engineering learns how a system is behaving at runtime and if there are things the development team could do to make the software perform faster. CAST is a design-time, proactive measure to avoid common performance problems in the first place.
Performance engineering is like taking a brand-new Mercedes onto the racetrack to see how it performs. The development is over, now you’re getting into fine tuning what you have. With CAST, we’re actually checking for structural problems while the car is still being built.
But I can see where the confusion comes from. The objectives of performance engineering are aligned fairly closely to those of CAST. When it comes to performance, CAST is intended for: eliminating late system deployment due to performance issues; eliminating avoidable system rework due to performance issues; and reducing increased software maintenance costs due to performance problems in production.
So, getting back to our car analogy, working with CAST is more like noticing that one tire on the car is smaller than the rest, or that two axles are not perfectly aligned, or that the engine is diesel while the spark plugs are meant for gasoline engines. These are issues that might not cause problems at low speeds, or right away, but after a few laps they’ll cause the tires to become bald or the engine to stop running -- not an ideal situation for a racetrack.
This distinction becomes readily apparent when we take these similar processes and set them on the same task: improving the overall performance of a system. Performance engineers might trace the round-trip time of transactions, figure out which parts of the process take the longest, and then take measures (adjust the network, change the indexes in the database, adjust table spaces, optimize where they have the most processing power, etc.).
With CAST, you start with standard performance rules applied throughout the application’s development. But, this is where performance engineers can have an even greater impact. Along the way, if they notice a certain pattern that’s causing performance to suffer, the performance engineers can turn it into a custom rule. Then CAST can check to make sure all developers avoid such patterns at all times.
I know that some of you are probably reading this and thinking that we’re just splitting hairs. And while it’s true that performance engineering and CAST’s processes might share similar outcomes, the real business value comes in its implementation.
CAST’s platform is best used during the design phase of a product, so that code problems can be checked while there is still a chance to fix them. Performance engineering is done after the product is finished, like a quality control test, to see how well you made out during development.
Combining the two -- with CAST streamlining the application during the design phase and performance engineering doing the fine tuning after its release and providing feedback to developers and architects -- is a strategic advantage that can be used to create dynamic, high performance, quality applications. This is an essential part of avoiding waste in Lean Application Management. So you can go ahead and call it splitting hairs, but I call it a competitive edge.