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

31–40 of 43 posts

Re: The Duct Tape Programmer

#31

Post by mannicken »

An opposite to a duct tape programmer is the "Cargo cult programmer".

He will research long and hard on the conditions in which programmers perform the best, then try to break programmers down to categories and figure out which one he fits into the best. Then he will research the psychological flow needed for programming and spend long hours planning out the IDEAL setting for the "flow to kick in". Then he will write a couple of articles on much flow rocks and how awesome it would be if everyone could achieve the perfect flow, and then go to sleep.

No actual programming (or even architecture astronautics) has been done during this process.

Re: The Duct Tape Programmer

#32

Post by j_baker »

Tichy wrote: post #6
PaddyCorry wrote: post #4

I work on enterprise software in a financial company, and IMO, this quote from Zawinski would lead to a dangerous short-term view in that context: "unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that." When you work in enterprise software, this approach might work on the first project, maybe the second, but eventually a point will arrive where a requirement will take l…

If you need unit tests, write unit tests. If you don't, don't. So in your case you would notice that for iteration 3 you need some unit tests. Then you can write them in iteration 3. You didn't need them in iteration 1, hence no need to write them in iteration 1. The concept of technical debt will probably inserted into the discussion here. I think it is irrelevant. Yes, there is always technical debt. For example, I…

The problem with that train of thought is that the point when you realize you need tests (you're shipping software with stupid bugs that could be prevented with a few tests) is often after the point at which it's easiest to write them. I'm not going to be the TDD zealot and say you need 100% coverage and you need to have your tests written up front. However, I will say that sooner is usually much better than later when writing tests.

Re: The Duct Tape Programmer

#33

Post by evilmushroom »

Short term prototyping only. Anything long term and big--- and you'll be hating yourself for not having clear standards and patterns. :P

Keep in mind you can make something that is overengineered suck hard too. There is a happy medium between over engineering and hacking together crap.

Re: The Duct Tape Programmer

#34

Post by may »

trustfundbaby wrote: post #30

I liked the article and I think it epitomizes this bullet list I saw here a few days ago 1. Make it work 2. Make it right 3. Make it fast All Joel is saying is that If you're up against a time constraint (like trying to ship code) ... its okay not to get to 2 or 3 right then and there. I think thats a good lesson for hackers to learn.

Link to original?

Re: The Duct Tape Programmer

#35

Post by fleitz »

Software moves so fast that you're always doing it wrong according to someone "in the know."

The point is to have a whole bunch of tools at your disposal, the knowledge to correctly use each tool to it's maximum effect, and the courage of character to use that tool despite its unpopularity.

If you take away from this article that shipping trumps all, or COM multithreading sucks, or templates in C++ are buggy, you're missing the point entirely.

Re: The Duct Tape Programmer

#36

Post by trustfundbaby »

may wrote: post #34
trustfundbaby wrote: post #30

I liked the article and I think it epitomizes this bullet list I saw here a few days ago 1. Make it work 2. Make it right 3. Make it fast All Joel is saying is that If you're up against a time constraint (like trying to ship code) ... its okay not to get to 2 or 3 right then and there. I think thats a good lesson for hackers to learn.

Link to original?

someone left it in the comments.

Re: The Duct Tape Programmer

#38

Post by hristov »

phaedrus wrote: post #20

This is the most irresponsible thing Joel Spolsky has ever done, and I lost all respect for him after he posted this essay. My bosses at my then-current workplace began using this article as an excuse not to do proper software architecture. I ask you, in what other industry would doing shoddy workmanship be considered an insightful viewpoint? Would you be happy if you discovered you'd hired "The Duct Tape Plumber" to…

"The problem is that it wasn't really air tight....."

So the problem was that you did not use enough duct tape.

Re: The Duct Tape Programmer

#39

Post by kls »

silentbicycle wrote: post #11
avar wrote: post #9

Earlier quoted context omitted.

A good reason to write tests for seemingly trivial code like that is if you're implementing an API that others will use. I've re-factored a class that implemented a public API and been saved by trivial tests that pretty much just tested getters/setters. But there's a time and place for everything. I rarely pass 95% test coverage, the remaining 5% are usually not worth pursuing.

If you're using tests to check your API integrity, ok, but writing tests by hand for getters and setters written by hand would be disgusting. Hopefully a very minor declaration in the code can automatically create all the tests.

I feel this is the responsibility of an audit system and not the code itself. I have never understood why people write code to verify a contract when it should be done as a rule in a proper SCM system.

A better process is to write or purchase plug-ins for your SCM system that audit all commits and either notify of a contract violation or refuses commit without a supervisors override. Enforcing contracts is not the domain of custom code it is the domain of SCM and therefore should be implemented at an SCM level. This way you write it once and everyone benefits whereas with test you are a. writing test for every contract and b. leaving in the hands of the current developer to ensure the contract is met. Further by having it audited you can build a process around that audit to guarantee that the issue is accounted for.

I am not sold on TDD, but I have not thrown it out as snake-oil yet either. It is in no way the harbinger of quality it was heralded to be, but logically there are some places that it seems like it can and does help but my general feeling about it in the way that it is sold (test everything), is that it is a wast of time.

Re: The Duct Tape Programmer

#40

Post by wanderr »

phaedrus wrote: post #20

This is the most irresponsible thing Joel Spolsky has ever done, and I lost all respect for him after he posted this essay. My bosses at my then-current workplace began using this article as an excuse not to do proper software architecture. I ask you, in what other industry would doing shoddy workmanship be considered an insightful viewpoint? Would you be happy if you discovered you'd hired "The Duct Tape Plumber" to…

That story reminds me of my own heater core troubles. I had an old car that sprang a leak in the heater core, dumping antifreeze all over the inside of the car. The cost of having someone replace the heater core and "do it right" was more than the value of the car, and I live in Florida so heat is really only something it would be nice to have 2 or 3 days out of the year. I didn't use duct tape, but I did use a $2 part and some zip ties to bypass the heater core entirely. The car lasted me 3 more years until I got tired of the other problems it was developing and finally decided to give it to a friend.

What's the point of my story? Perhaps duct tape isn't always the best solution, but there are certainly times where the application of duct tape (or zip ties) is an appropriate response, the trick is identifying when and where, and being willing and able to do it when it makes sense.

Post reply on HN