The title could use a "(2009)" - I thought this was a new joelonsoftware article.
The Duct Tape Programmer
11–20 of 53 posts
Re: The Duct Tape Programmer
#12Currently rewriting every single line of UI code a pile of duct tape programmer spewed out over the span of two years. Writing functional tests so I know when I break the UI. Documenting everything. Hitting all deadlines. Using multiple inheritance. Lots of It. In fact, no file is over 150 lines long. Composition pattern in full effect as well. I hope it wards off duct tape programmers for life. > 2015 > multiple inh…
Composition...isn't the same as inheritance?
Why not do both?
http://programmers.stackexchange.com/questions/134097/why-sh...
Re: The Duct Tape Programmer
#13Right now I'm working on save/load for a game that is overflowing with duct tape code. Yes it shipped and did well. But now I'm paying for all the sins of all the duct tape used by all the coders. I'm not sure I'd change anything in the past but I do reserve the right to bitch about things written that aren't fully correct but close enough... until save/load is considered and then it just doesn't work at all. Grumble grumble grumble...
Re: The Duct Tape Programmer
#14The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.
Re: The Duct Tape Programmer
#15Re: The Duct Tape Programmer
#16This is a great article, but the comments make me feel like I'm twice as old as I actually am.
I think that maybe if we called these programmers "gaffer tape programmers", some of the sense might be clearer to programmers who've come to the field (like me) from a linguistics and theatre background, not a traditional mathematical one.
Re: The Duct Tape Programmer
#17Right now I'm working on save/load for a game that is overflowing with duct tape code. Yes it shipped and did well. But now I'm paying for all the sins of all the duct tape used by all the coders. I'm not sure I'd change anything in the past but I do reserve the right to bitch about things written that aren't fully correct but close enough... until save/load is considered and then it just doesn't work at all. Grumble…
This is a great thing to grumble about. It's also a great thing to only fix enough to hit your performance targets. But you probably already know that :)
Re: The Duct Tape Programmer
#18The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.
I think that confusing "duct tape", "gaffer tape", and "crazy glue" is a problem in any kind of shop. Maintainable glue code is more like painter's tape or gaffer tape than it is rubber cement, imo.
Re: The Duct Tape Programmer
#19Multiple inheritance often makes it extremely difficult to tell where my code is coming from.
When you don't use inheritance, you often get to refer to another module by name. E.g.
`my_dependency.fetch_data(123523)`
With multiple inheritance, however, that other module has become your own "self"!
Suddenly you're stuck with:
`self.fetch_data(123523)`.
And if you want to find the source of `fetch_data()`, you basically have to grep / look through all seven of your base classes.
If you're lucky, the definition you were looking for calls `self.flush()`, where `flush` isn't defined on this class. It's actually intended to be defined on another base class, which is imported by the multiple-inherited subclass.
So, you effectively have a "DSL" whose "statements" consist of your choice of base classes. It's impossible to determine what's a legal "program" in this "DSL" until you run the thing and get method-missing errors.
Re: The Duct Tape Programmer
#20'Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”'
I couldn't agree more. That's what I cut out as well when up against a deadline. The problem is, when is one not up against a deadline in the professional world?
Because of a combination of no planning, bad communication, and just plain laziness on the part of product, I got a chance to see what not being up against a deadline in the professional world is like. For a few months, my team wrote beautiful code, did in-depth code reviews, tested everything that could be tested, and dotted all the i's and crossed all the t's. To be honest, the pace fell even more than I expected as other team members who didn't know when to leave well enough alone just kept on making or suggesting unnecessary tweaks and re-factorings. While it was slightly cleaner and better, the code we wrote then was only marginally so compared to the code written in haste at crunch time. If I had to put a number on it, it'd be ten percent better. For two or three times the amount of time and effort put into it. The point is that there is always a balance that needs to be found.
I have seen and worked with the type of code that Joel refers to and it's definitely just as bad as any spaghetti. I have also worked with people who intentionally over-engineer or spend a lot of time on unnecessary minutiae that overly complicates code and the design. These are real problems indeed and they lead to code that looks nice from a bird's eye view and even a short inspection but leads to screaming when you have to work on it. I think both the duct tape engineer and his opposite are both extremes to be avoided most of the time.