When I was a kid, my bedroom walls were plastered with posters of Lamborghinis (mixed in with the occasional poster of your favorite eighties hair band). The image and branding of Lamborghini is the epitome of performance and sex appeal in the most extreme sense. It turns out that the love for these cars is genetic and my 12 year old son shares my obsession.
This slick image is something we all try to achieve with the things we build. Our customers always have the requirements to build their software so it’s fast ... like “Lamborghini” fast! However, often times they find in the end they really built something else …
Enter the Yugo! If it were, as my 12 year old would say, “opposite day,” then you would be driving one of these cars instead, the shining star for the automotive industry where economical violently crashes into ugly. I believe these cars went from zero to sixty in 30 minutes, with your friends giving you a push start. Fred Flintstone and Barney Rubble could peddle their car faster.
Unfortunately, sometimes our software shares the same characteristics of a Yugo, and we start to ask the question, “How did we get here?”
Most of the time our customers blame having Lamborghini speed in their software process on time-to-market demands, which causes them to push off performance until the end (because features are more important). In the worst of cases, by the time our customers come to this conclusion they realize the impending decision of COMPROMISE. In other words, the software may have the sex appeal of a Lamborghini, but when you step on the gas she doesn’t go. Most of the time they have hard wired performance into their architecture and to correct it is major surgery and very expensive. However, all is not lost! Software, unlike actual cars, can be “bent” and changed much easier and in a lot of ways that have a material impact to its performance.
From our experience as a company, performance tuning software is a unique capability and not every software organization has the correct mix of talent, technology and, most importantly, time to pull it off themselves. What we also find is the definition of performance varies across projects and even with projects across engineers. It’s understanding the definition the market deems most important and how to focus on those targets as the priority; the rest of the performance requirements can be addressed over several releases. Another key factor is the economics of this activity. Providing fixes that first emphasize the maximum improvement to performance with the lowest impact to architecture is the priority.
We know that it’s hard to take a step back from the wonderful work you created and realize you began the journey wanting to build something sexy and fast, but unfortunately today was opposite day. The team’s intention was absolutely in the right place, but the speed of process and other competing priorities interfered with our dream of building our Lamborghini. Rest assured, there are ways to engineer performance back into the software, so in the end you may not have the Lamborghini, but you definitely won’t have a Yugo, instead you might end up with …
Yup … you knew this is where I was going. She’s not sexy and she’s not ugly either. She’ll do zero to sixty a heck of a lot faster than both a Yugo and Fred and Barney. Lots of utility and incredibly reliable with mass market appeal. Yes, folks, this is what most of us (including me on weekends) drive.
Why should our software be any different?
PSC, Vice President