Always choose simple
Today I was tasked with something rather trivial at work, and I wrote the simplest, dumbest code possible to solve the problem. A colleague of mine was surprised looking at my patch, she said it's so simple and beautiful, as she expected some more involved cleanup or refactoring. This brought to mind a little story I'd like to share.
When I was 20 I got my first job at a startup. The product we were working on could now be described as a CMS (“Content Management System”), but it was quite advanced and ahead of its time. Those were days when Netscape Navigator was still a thing and if you made a website, it better work well on that piece of crap browser. I used to envy people with Windows, because Internet Explorer 4 was clearly better than Netscape.
Our CMS was a full blown product, with the client (user interface) written in Java. Java stood to its promise — write once, run anywhere. But you better run it on Windows, because on Linux the Java experience was utterly miserable — slow and horribly ugly. But I digress. Our CMS also had its own in-house HTTP server, database abstraction layer, PDF generation library (I wrote that), and on and on. Tons of components. As a C++ engineer, I worked on the backend. Junior as I was, I knew C++ for years and considered myself pretty good. I took the interview with flying colors. I knew all those arcane details like static_cast vs dynamic_cast, templates, memory etc. heck, I was even comfortable to write assembly code. Yet there was this guy, Rykov (Alexander, I think?), who was a senior and constantly rated our code like 5/10 in reviews. We kinda hated him.
One day me and a colleague were tasked to figure out why our server is only able to process like 0.7 requests per second, and how can it be improved. Boss even promised bonuses proportional with the improvement percent. After much digging, we did find an improvement so big that our bonuses would have gone through the roof, had he kept his word. Here it is: the main entry point to our server was a single C file, pretty small too. That one was written by Rykov entirely. It just waited for incoming connections. When a request came in, it forked a child process to handle it. The child terminated after each request. By poking around the code, we figured out that if the child *didn't* die after the first request, it served the second one much faster. By *much faster* I mean something like 50 times, if I recall correctly. We were baffled by it. We measured how much time it takes to fork, because we thought that was the bottleneck, but it wasn't. The fork() call itself took exactly 0.0 milliseconds every time. Eventually we figured out that that's how it works. fork() is instant because it doesn't really do anything, it just creates a child process — but when it first runs, that child process will need to duplicate memory that it shared with the parent, to eventually create a full copy — it's copy-on-write. The first run is always slower, and by terminating the child after it served a request we effectively lose the opportunity to serve a subsequent request much faster. All this is common knowledge, but it was new to us then (oh, so that was the reason why Apache had a worker process pool!).
So any case, we reported our findings and over the next few days we started to put together a comprehensive infrastructure for handling a worker process pool, with tons of objects like service factories and monitors and configurators and what not. The C++ design patterns book was still a fresh success at that time. We wrote hundreds of lines of code which wasn't yet working because there were still missing methods and objects and abstractions that we had yet to invent. And then one day we learned that Rykov had already committed a 10 lines patch that does the job just fine.
I looked at his code in disbelief. I forgot the specifics of how it worked, but I remember being amazed at it. It was small, simple and beautiful. And I was pissed that I had to drop my grand architecture on the floor, but I had to admit that his 10 lines patch worked well and there was no reason for all the crap I wanted to come up with.
I don't remember if I ever told Rykov about that feeling. I was too young, too proud, maybe too full of myself. But I learned the lesson. Mr. Rykov, if you're reading this by any chance, I hope you are well! :)