1. 10
  1. 15

    The duct tape programmer referred to in TFA, jwz’s response: that “duct tape” silliness

    1. 9

      No offense to Joel, but in retrospect isn’t it this attitude that led to software not working reliably and being full of security holes? To the degree that anyone working in the field doesn’t trust any object that has software in it?

      Certainly in some applications it may be more important for the software to be released than for it to be free from bugs or secure, but I think this attitude may have been less problematic when computers were less networked than they are today (and everything wasn’t a computer). In the present day, a computer without an internet connection is more of a toy than a useful tool for most purposes, whereas I can remember as a child using my 386 or Gateway computer quite happily for productive tasks with no connectivity at all before we got AOL. (Today I would struggle to install any software at all without an internet connection. Even if I had the software on physical media that my computer could connect to, which is not guaranteed on my Macbook Pro with no optical drive or USB-A ports, if anything went wrong I’d need the online documentation, a search engine to find tips from people who have run into similar problems, access to relevant IRC channels…) A computer connected to the internet is not secure, and the buggier and less secure your software is, the higher the chance your users will experience harm as a direct result.

      I think it’s widely acknowledged that we need to rethink the mantra of “move fast and break things”, and that may need to start with how we write our software.

      1. 9

        And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever […]

        This was surprisingly triggering for me. As someone who tries to share (what I think are) neat bits of tech trivia and then get slammed as a nerd (in a room full of programmers no less) this is really demotivating. I know you need to “know your audience”, but people also tell you to “put yourself out there”. Persistence seems to be key: eventually you’ll find like-minded people. Eventually…

        1. 5

          I have a feeling you could have brought up the weather, or last night’s sportsball game, and the response would have been the same.

          This biz does not seem to attract the nicest people. Look at how JWZ responds to people on his own blog… when they’re trying to help! I think JWZs are the rule in software rather than the exception.

          1. 1

            I think it’s just a mistake to think there are many interesting categories that include ADTs and CORBA and let you make generalizations about them. Talking about “abstractions” without making clear which kind of examples you’re talking about is way too common, though.

          2. 7

            My career has been basically cleaning up after duct tape programmers and what they don’t tell you is how many companies go bankrupt because they just can’t keep the code base working. A recent gig had a duct tape programmer as the tech lead with the result being an maintainable mess that will cause them to go out of business within 2 years with national security implications.

            1. 5

              Yeah, but would the company have existed otherwise? The counterfactual is hard, but given that most successful companies find themselves having to fix security failures perhaps it’s actually a dominant strategy to build fast and fix later.

              Are there non-security-focused companies that have a reputation for having built things right in the first place?

              1. 3

                Yes. It would have done the work with people instead of computers. It would have never become the largest company in its space but that’s a feature.

                Socially the dozens of white collar jobs that were eliminated would have stayed and the knowledge that the people had would have been preserved and passed on.

                The biggest problem at that place was the fact that no one knew why anything was done. So I was reading 20 year old SQL business rules and translating them verbatim to modern languages with no idea why.

                If that’s not the definition of a dark age I don’t know what is.

                The only solution I can think of is literate programming.

            2. 3

              Has anyone read the book that inspired this article (Coders at Work)?

              1. 4

                Are we going to fly over the fact that this article comes with multiple strong requests for you to go buy a book on Amazon, without mentioning that the author has added his affiliate id to get some cash from it?

                All that together with all the usual waste of text on “generalized decent IT person A” vs “generalized awful IT person” that we are forced to follow?

                Yeah, sometimes you gotta duct tape stuff and move forward without unit tests and sometimes you’ve got to design, plan and study your problem, while making sure the components are stable enough for release.

                I wouldn’t want a duct tape engineer working on a complex system in the same way I wouldn’t want the other type while working on a rough MVP as a proof of concept.

                So, yeah, yet another useless article to create yet another us vs them within ourselves.

                We should strive to find ways to improve our field and not just cuddling ourselves because we fit in category A or B.

                1. 2

                  Not a fan of this article, even though I think it’s dancing around some points that are true and valuable enough.

                  Joel is arguing that there are a bunch of specific programming technologies - he cites “multiple inheritance, or templates, or COM, or multithreading”, and even the C++ language itself - that are “too hard for the human brain”. Insufficiently-pragmatic programmers are tempted to use these abstractions, causing more complexity cost than they are worth, and therefore it’s desirable to have a pragmatic “duct tape programmer” on a software developer team is willing to shut down people who want to use these before they commit the code. This is broadly, almost vacuously true - yes it’s possible to overengineer a piece of software, yes complexity of abstractions has a cost in maintenance and teaching, yes part of being a good software developer is knowing when this is the case and pointing it out to your team. The hard part is knowing when this is and is not the case. It’s knowing what specific things are and are not pragmatic, and when.

                  It’s worth noting that this article was written in 2009, and he isn’t citing details of any subfield of software development other than PC desktop software development in the mainstream languages available in 2009. And I think that’s ultimately what limits the usefulness of this essay. In the 2010s, a lot of complicated technologies that aren’t the ones he mentioned became trendy or rescued from academic obscurity - technologies like pervasive typechecking and abstractions for expression-oriented, function-style programming and even widespread availability of javascript runtime environments - became widespread, and a lot of these actually were good ideas that improved the software development experience. Joel was picking out a bunch of specific abstractions to label as bad because those abstractions were bad, but that was nowhere near the entire space of available abstractions.

                  A line like “Sure, there’s nothing officially wrong with trying to write multithreaded code in C++ on Windows using COM. But it’s prone to disastrous bugs, the kind of bugs that only happen under very specific timing scenarios, because our brains are not, honestly, good enough to write this kind of code. “, for instance, looks a lot different in 2019, now that Rust exists. Rust, of course, is a (deservedly) popular and trendy technology which is 1) complicated and 2) deliberately designed to solve the problem of writing multithreaded code safely. The problem wasn’t trying to write multithreaded code, it was that in 2009 the correct abstractions that you needed to do it without memory safety bugs only existed in research language and it would take several years of engineering work to create.

                  I don’t think a “duct tape programmer”, at least not the one that Joel describes, could figure out when a complicated programming technology like static typing is genuinely useful and when it’s too complicated, and would thereby have missed out on a lot of the abstractions that make programming today genuinely nicer and less bug-prone than in 2009.

                  1. 1

                    I don’t think a “duct tape programmer”, at least not the one that Joel describes, could figure out when a complicated programming technology like static typing is genuinely useful and when it’s too complicated, and would thereby have missed out on a lot of the abstractions that make programming today genuinely nicer and less bug-prone than in 2009.

                    Sure, maybe not in 2009, but a duct tape programmer today would have a different outlook. The point isn’t the specific technologies, it’s the attitude - “pragmatic duct tape programmer versus head-in-the-clouds architecture astronaut”.

                  2. 2

                    This article made me cringe when I read it in 2009 and it makes me cringe even harder today. Thinking like this may work when you are a startup and need to ship ASAP but that just doesn’t fly when you need stability and money/lives are on the line.