Too Many Tools and Frameworks (2015)
I&#x27;ve been a coder and have watched coders for a long time. I consistently see two trends.<p>As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile&#x2F;to-do list tool.<p>It seemed that programmers were unable to grok the agile story concept without making their own tool to use it.<p>But I saw the same kind of thing in the code I wrote. I wouldn&#x27;t just solve a problem; I&#x27;d solve a class of problems. Generalization was awesome! The more I generalize and account for edge cases, the more value I am creating! Woo!<p>Many of us programmers, myself included, are constitutionally incapable of just solving the exact problem we have using the minimal amount of code and then moving on. <i>We confuse coding with value creation, so we build frameworks and tools out of everything.</i> If you build a list sorter, that&#x27;s okay, but if you build a 30KLOC list uber machine, that&#x27;s better, right? After all, it does more. You worked harder at it.<p>The second thing I saw, which was even more painful to realize and accept, was that it was very easy to get &quot;upside down&quot; in a toolset or framework and not even be aware of what&#x27;s going on.<p>The first time I saw it was when I was teaching a mainframe team Visual Basic, back in the 90s. We were building a simple form with a textbox and button. I had showed them the concepts and they were a smart bunch. I started the exercise, but a couple of developers were stumped.<p>Why?<p>When I walked over, the problem they had was the properties page. Sure, they got the concept of drag-and-drop. But once the button was dropped? There were like a million options in there! What was the right font size? What did this thing mean? And so on.<p>I thought that was pretty silly and tried to forget it. But then I noticed in my own work that I&#x27;d get sold on a new set of tools. For sake of argument let&#x27;s use the old Infragistics web controls. They do everything! Amazing control and look-and-feel!<p>I&#x27;d drop them on a web page wanting to create a smart grid. But the grid didn&#x27;t do X, and in my mind, X was what needed to happen. So I&#x27;d poke around at the help file. I&#x27;d go online. In some cases I&#x27;d tear apart the javascript and start fixing it myself. Hey, it&#x27;s only web programming. I can do this.<p>But holy shit that took a lot of time. On my next project when I needed a grid? I dropped a HTML table in. Just added whatever functionality I needed directly from JS. Not only did it take less time, but the resulting codebase was easier to read.<p>Then I started watching the teams I coached. They very rarely talked about actually solving problems, or language&#x2F;foundational issues. Instead they talked about tools and frameworks. This tool or framework would do this cool thing if you tweaked it like this. Joe spent 2 days trying to get Y to work.<p><i>For many, many teams, buying into the framework means buying into a complexity and cognitive overhead that&#x27;s siomply not relevant to the actual problem they&#x27;re trying to solve.</i> I don&#x27;t know. Maybe it makes them feel cool or something. One of the smart kids. But speaking as both a participant and an observer, it&#x27;s whack.<p>tl;dr So sure, let a thousand flowers bloom. But your job isn&#x27;t arranging flower baskets, it&#x27;s helping somebody who&#x27;s down feel better. You might not even need flowers at all. Stop focusing on the tools and start focusing on the solution. Then the tools will work themselves out.