The story is obviously intended to teach a lesson and not a real piece of truth. But the lesson is real, and we’ve all seen it in action. Product people want t

The story is obviously intended to teach a lesson and not a real piece of truth. But the lesson is real, and we’ve all seen it in action. Product people want to push products. Management wants to manage. Engineers want to engineer. Nothing about any of this is inherently bad, but putting these three motivations together in a vacuum can have this effect. This is all, in my opinion, an example of resume driven development. Everyone wants to build themselves up. In a competitive market, you have to. For product people that means delivering products, for management people that means managing problems and finding successful solutions, for engineers that means engineering cool shit that works. We are strongly motivated to behave this way. The point of the parable is that these motivations don’t necessarily lead to the optimal solutions. And that the difference between the highly productized, well-managed, elegantly engineered solution and the quick fix is often not large. But there’s a strong reaction against boring solutions. Boring solutions don’t get you the next gig. Boring solutions don’t impress anyone. Boring solutions don’t make your resume pop. This is a grossly exaggerated example, of course, but that’s how parables work. I’m kind of surprised by how many of the comments are missing the point. This tendency to over-engineer, over-productize, and over-manage is everywhere in the tech industry. We do it everywhere. Not to start a flame war, but I’m Looking at you, new JavaScript framework flavor of the month. I’m looking at you, infrastructure platforms and noSQL solutions. The thing that we don’t seem to be able to accept is that the vast majority of the problems we solve day in and day out at our startup companies and our big big companies are very straightforward and boring problems, for which there already exists a boring solution. This is more specifically true of web development than native dev work or embedded systems, and there are obvious places where this is entirely untrue. Cutting edge research in theoretical comp sci, embedded systems, AI, and cryptography. And I say this as a web developer, not one of the other interesting things I mentioned above: most of what we do is and should be boring. They are simple interfaces to data. A very few of them—-maybe .01%—have to actually deal with scale. I know I sound like a grumpy old man, but that’s increasingly what I feel like. One of my most recent projects reflects this so closely that it’s not even funny. We had a project without enough time, we wanted to bring in a vendor to deliver a system-wide platform. Vendor couldn’t deliver on time, so we had to do something else. My solution took a day to prototype and another few days to deploy. It was boring as fuck. No one would be even remotely impressed with the implementation. It was a boring problem with a boring solution. But it solved the problem, and we were free to move on to something else. If we want parables like this to go away and stop offending us because they aren’t literally true, we (especially us web developers) need to stop pretending that we are so special. Product and Management should also do the same thing. Most problems are boring, and they deserve boring solutions. Yeah, I know that doesn’t help your resume or mine, but you don’t get paid by a company to bump your resume. You and I get paid to solve mostly boring problems. Until we are willing to admit that to ourselves and each other, this parable is going to remain relevant.