“GUI components often work but do not always scale”

Climbing … Ted looks bad; not injured but he’s flushed, drenched, and lactic acid buildup has made his forearms look like useless swollen tomatoes. In climbing they call it being pumped and it’s not good.  We are 400 feet up an “easy moderate” climb.

“I don’t understand”, he says, “I climb routes twice as difficult in the gym”

“Ted, in the Gym, the routes are only 25 feet high and you don’t carry gear”

“I need some endurance training”

 

A performance analyst says, “Ted, every time I load the detailed report page with a large database, the client CPU usage spikes unreasonably – it all seems to be in TableX.js”

Ted says “Yeah, TableX is a widget that I got from another division.”

“OK when can we get a fix?”

“Well, there was a reorg., so it’s not clear who owns it now.  Might be a while.”

Components and Frameworks are great; we couldn’t hit our deadlines without them. However, it’s not a given that all the code that we reuse will actually support the scalability our web site requires.  Also, there is a risk that while the components can scale, the way that our code uses the components causes them to fail under heavy load.  It can be difficult to get fixes to imbedded components and can be expensive to reengineer our use of the components.  What can be done?  We all test the components that we use, we code prototypes and proof-of-concepts, but how do we avoid unfixable scalability problems many months down the road?  

One solution is simple and practical; most programmers write test code to verify the functionality of components before imbedding them in a solution and it’s possible to tweak that code then quickly retest to reduce the risk of future scale problems.  First, we can think about exactly how we plan to use the components and write our test driver to mimic that usage pattern.  Second, we generate larger set of scaffolded data to mimic the absolute maximum scalability we expect for that component. We make our test drivers, prototypes or POCs mimic what our fully scaled product would do with the components and we watch for slowness, high resource usage on the server and the client.

Nobody likes surprise scalability problems late in development, especially if the problems are almost unfixable.  It’s worth a few hours early in the development schedule to test component scalability and reduce the risks.