Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Duct Tape Programmer

joelonsoftware.com

Post reply on HN
Print view View original

41–50 of 123 posts

Re: The Duct Tape Programmer

#41

Post by azanar »

Tichy wrote: post #25
tdavis wrote: post #23

You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tests or use higher-level abstractions doesn't automatically make him better than other types. Some of the smartest programmers I've met have been religious about TDD and strict formatting and commenting and as a result maintain and work on some incredibly large…

"I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.

So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.

Another possibility is that it is important, possibly even more important than the other things they are working on, but isn't getting prioritized for other reasons. They've succeeded thus far with the way they have prioritized things, but that doesn't mean that they made all the right choices, it just means they made enough right choices to survive to this point. The future may prove tdavis painfully right in his concern about not having test cases. Another company that may not have made enough other choices correctly may be able to cling to having tests and deployment automated as the thing that saves them. I don't think you can draw any real correlation except that it might not be that important, and only time will tell.

Re: The Duct Tape Programmer

#42

Post by kentosi »

wallflower wrote: post #11
dangrover wrote: post #3

Maybe Netscape's duct-tape programming had some side-effects though... http://www.joelonsoftware.com/articles/fog0000000069.html

A consequence of those rewrite side-effects: Mozilla Firefox was forked from the rewritten Mozilla codebase > Netscape 6.0 is finally going into its first public beta...Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. http://www.mozilla.com/en-US/firefox/releases/0.1.html http://www.mail-archive.com/linux-u…

You're confusing two different things here.

Re-writing a codebase to spawn a totally seperate application is not the same as when you're doing it to re-release an enhanced version of the same application (with a bumped up version number).

Re: The Duct Tape Programmer

#43

Post by azanar »

rbranson wrote: post #24
fjabre wrote: post #9

Awesome read. I couldn't agree more. I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'... While I think eventually one would refine their product so that it uses best practices I would say that having custo…

Yes, thank you. The moral of the story is that you ship a product first, then you tweak, improve, and refactor it once you've got a reason to!

If you do that, you'll run a very considerable risk of wonder why version 2.0 of your product is taking so damn long to ship. The answer: all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0. Now all these have set your code in concrete, and you have to remove half the foundation to get them back out.

Re: The Duct Tape Programmer

#44

Post by mkramlich »

clutchski wrote: post #20

"And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.” By all means, ship. Do what you gotta do. But a code base that doesn't have tests cannot safely be refactored. This technical debt must eventually be paid by the product owner in cash and the code's maintainers in sanity.

I disagree with your statement that a codebase without tests cannot safely be refactored.

I've been refactoring code for 20+ years, the overwhelming majority of time without any automated tests, and I'd say offhand 99% of the time it causes no bugs, and in the occasional case where it does cause a bug (because I am imperfect and sometimes make mistakes), I almost always soon find it during the same coding session and fix it.

The key is to understand the code well enough to know what effects what and how. Hold that model in your mind and you're golden. Lots of time saved not writing tests, updating them, fixing them when they break, etc.

Note that this is not an argument against tests in general, just an argument for there being cases where you don't miss them and they would be a net loss if you had them due to all the extra make-work required. I think there's a lot of kool-aid drinking going on among people who themselves probably lacked the ability to do "naked" refactors well. To those folks I say, "Great, have fun storming the castle!" but don't assume that other folks who haven't drunk your kool-aid are constantly banging their head on the wall breaking the code or living in fear of mysterious hypothetical bugs due to a lack of tests. A really excellent 'old fashioned' sort of test is to just run the fricking code -- did it work? did it do what it was supposed to do? data look good? k, move on to the next one of the thousands of other problems you have to solve and tasks you have to do in life. And use version control, so if you retroactively do discover a problem, you can review the diffs, or rollback, or do a tactical patch against the branch, etc.

I do agree with your statement, "By all means, ship. Do what you gotta do." And I agree that that attitude may cause you to at least temporarily incur technical debt, and you generally want to pay that down as soon as feasible. (backing out ugly hacks to replace with more elegant or easier to read implementations, etc.)

Re: The Duct Tape Programmer

#45

Post by abalashov »

mrshoe wrote: post #19

Just remember that this principle applies doubly if you're a startup. And it applies doubly again if you're an early stage startup, because you're still deciding what to build at that point. Astronaut architecture is a complete waste of precious time that you don't have.

It really depends. If you put together such a kludge that you're going to have to completely rebuild it to scale past a nontrivial quantity of initial customers, you would do well to put at least a little thought into the theoretical foundation of what you're doing.

Re: The Duct Tape Programmer

#47

Post by mkramlich »

Triston wrote: post #16

I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work. Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial rele…

I worked at Orbitz which has a huge Java codebase. It was complex and hard to maintain. It was loaded with abstractions, interfaces and unit tests. I believe the former was mostly due to the latter.

Not to say that the latter has no merits -- there are situations and cases where they are 'net win' good things. But when overdone or done poorly they make a codebase much harder to understand, troubleshoot, extend or fix.

I've seen this first-hand many times, though I notice it most often occurs in large corporate Java shops rather than with smaller companies or codebases or more nimble/concise languages.

Re: The Duct Tape Programmer

#48

Post by elviejo »

kentosi wrote: post #33
KevinMS wrote: post #13

"One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project." Like writing a custom compiler for your web app? http://www.joelonsoftware.com/items/2006/09/01b.html After he jumped that shark I don't read anything he writes anymore.

That article was from 2006. I'm sure that his (and many other people's) viewpoints change over the corse of 3 years.

Noup They still use Wasabe. He mentions it often on his podcast. And I don't think it is such a bad idea. It is simply a translator from one languate to another. Like GWT (Google Web Toolkit) They program in Java however the result is 'translated' to javascript. That is how the Gmail UI was made.

So no that crazy

Re: The Duct Tape Programmer

#49

Post by hbien »

elviejo wrote: post #48
kentosi wrote: post #33

Earlier quoted context omitted.

That article was from 2006. I'm sure that his (and many other people's) viewpoints change over the corse of 3 years.

Noup They still use Wasabe. He mentions it often on his podcast. And I don't think it is such a bad idea. It is simply a translator from one languate to another. Like GWT (Google Web Toolkit) They program in Java however the result is 'translated' to javascript. That is how the Gmail UI was made. So no that crazy

Google only uses GWT for their internal projects. Gmail's UI doesn't use it.

You're right, though, it's not that crazy of an idea.

Re: The Duct Tape Programmer

#50

Post by tdavis »

Tichy wrote: post #25
tdavis wrote: post #23

You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tests or use higher-level abstractions doesn't automatically make him better than other types. Some of the smartest programmers I've met have been religious about TDD and strict formatting and commenting and as a result maintain and work on some incredibly large…

"I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.

On the topic of testing, it's only currently viable to write tests for bugs which occur in the future and that are properly caught (I recently caught one completely by accident because it wasn't caught by our alert system). Going back and trying to write test cases for everything I've written up to this point simply makes no sense; they should have been written before the code, from the start (or from a point that I knew the code wouldn't be re-written again).

Automated deployment has been less of a priority because I don't really have to re-deploy that often (meaning spin up a new server). However, if/when I do need to, it will be automated. Even if I haven't written the scripts yet, I will do it before the new machine comes up.

Back when the system was created I had never been a "TDDer" before and the tools that exist now did not exist or were not viable for production, especially in terms of automated deployment and dependency management. If I could go back and do it again (or just murder someone) I'd love to have good test coverage and automation tools. It isn't that it's not important, it's just that the ship has sailed on half of it and the other half is situation-dependent at this stage.

In summary, it is THAT important. I will go as far to say that I think these two items in particular are more or less vital to the long-term viability of a software project. Anyone maintaining a large, aged project that contains no test coverage and no automated build / deploy tools has my deepest sympathies; it's like stacking an infinite house of cards.

Post reply on HN