One thing I try to reinforce with clients, particularly those who have "big" projects, is that they need measurable success criteria. Sometimes that's dangerous because numbers can be gamed—such as the support manager who won an award for reducing support calls, only to find he had hidden the support phone number on our web site—but if you have measurable goals, you can use that to declare success or failure, rather than punting on the problem.
Case in point is my favorite "successful" project: I was with a company that decided to rewrite a massive Perl system in C++ because Perl was too slow.
Already, I know several of you want to know what "too slow" means in this context, but no, you gotta wait for the punchline.
This project was written years ago and was thus "legacy" code. It was clunky, but critical. Honestly, fixing it would have been cheaper and faster than a rewrite, but you probably know that. The dangers of rewrites are well-known.
But it didn't matter. Perl was too slow, so C++ it was.
And unlike many rewrites, this one was finished. It took them years, but they finished. The new code was a bit of a pig, but they finally lifted the millstone of Perl's performance from around their neck.
But there was a small problem. Turns out the C++ system, years in development, a steaming pile of ones and zeros, and possibly just a wee bit unmaintainable ...
... didn't run any faster than the Perl system it replaced.
You know what makes software slow? Network congestion. I/O issues. SOAP instead of JSON. RPC. Oh, and the database. It's always the database. Unless a system is CPU-bound, changing the programming language will often gain you no performance improvements!
The new project was started years ago, so when I asked, no one was sure if the system that was "too slow" had any performance profiling done to find the bottlenecks.
But management crowned it a success anyway, because now that it was done, no one wanted to admit that its only measurable success criteria showed it to be a complete failure.
When I left the company there was talk—I'm not kidding—about rewriting the system in Perl.
Top comments (3)
I remember in one of my previous engagement- upper management wants to rewrite a Perl Catalyst app to Java Spring because "it is slow". However, I haven't seen any profiling. Later on I came to know, the organization has every product based in Java and they don't want this Perl application(just because its Perl). Last time I checked, they drop the idea of rewriting.
"The dangers of rewrites are well-known" I like this sentence
I am working a meetup about optimization in general. One key point of this presentation will "understand what should be optimized, what should not". The other is "measure, measure, measure". Your article goes exactly in the same direction! Thanks for sharing this experience :)