Every once in a while I find a fun post that makes fun of programming. I think because the author is struggling with some piece of code, they write about the craziness of software development, often with an analogy that compares building something in the real world to how software programs get written. Here’s one, with a bridge construction analogy, that degenerates into a rant on the disparate ways in which different programmers work together and how the entire world of the Internet is held together in a constant patch-fix loop.
I do think that most large software applications have a decent amount of inconsistency. I’d suspect most large databases (in terms of object count), also have a variety of techniques, tools, and standards in use. That’s because the tooling that we use to build things change. We don’t have the constraints of the real world, which is why we could have a stored procedure using a subquery to calculate a running total and another one that uses the OVER() clause.
We can be more consistent in SQL because the language doesn’t change as quickly, but in application code, frameworks, techniques, and even libraries come and go constantly. Different developers have favorites, and without strong controls that limit the experimentation of your staff, likely your code base has a variety of styles and algorithms that do the same thing. Static code analysis, linters, and unit tests can help ensure your code runs effectively, but it still likely has sections that no one wants to touch.
This flexibility can be maddening to developers, especially when they start a new position. At the same time, each of them probably thinks there are a few places where they think they can write the code better, and they will attempt to do so, even if they are creating more inconsistency in the project. Multiply this by the 40% of programmers that are willing to make changes without trying to mimic how others write code and pretty soon the architect (if you have one) has no idea how anything works.
In the real world, we can’t easily get things to work together if they are disparate. We don’t suddenly change from framing one wall with a 2×4 to another with a 2×6. We might use different size nails or thinner brake pads or any of a number of other changes from one place to another, but often those differences don’t matter. At least not enough that we find houses and bridges constantly falling down. Of course, the workers building those structures follow a set of plans and standards, using similar tools and techniques.
That doesn’t happen in software, where you are often not limited by external constraints, but often your imagination. We can construct things in software that no one ever thought of before, we can grab materials, i.e. code from Stack Overflow, and use them in our system. Often builders don’t get to source materials from wherever they want, which inherently limits the variation between parts of the structure. That being said, lots of little mistakes get hidden in construction projects, just like they do in code.
I don’t think programming sucks. It’s always an interesting challenge, and I do think that when you have a group of developers that care about their craft and are trying to work together to solve a problem, we get some amazing software built and deployed. It might not be consistent or pretty, but often it works very well. If it takes regular maintenance, that’s fine. It’s an ongoing challenge that keeps us employed.
Steve Jones
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
Voice of the DBA 