How to distinguish duct-tape programming from Front-Ahead programming?

Question

I recently read this article from Joel: The Duct Tape Programmer, I immediately thought of this ironic TDWTF article: Front-Ahead Design.

I know of some crappy implemented applications, which suffer from all kinds of defects and frequently result in endless bug fixing sessions. But everything done wrong with these applications could be easily justified by being duct-tape-coded.

Especially the Code Light, Not “Right” and the Learn To Deal rules from the (ironic) TDWTF article seem to be mirrored in Joels (serious) article.

So, where can one draw the line between both coding paradigms? Because both sound very similar, how can one expose Front-Ahead programming when someone justifies that coding style as duct-tape programming?

Answer 1

Judge a tree by its fruits.

Presumably there is some reason why you feel you want to distinguish types of programmer.

If someone says they're an X, and they're not succeeding, help them to become a more realised X rather than labelling them as a failure.

Answer 2

It is difficult. The best way is to evaluate the results of his work, which will require some time to have passed.

Initiate a conversation on the matters of architecture, quality, maintainability, loose coupling, not repeating yourself, avoiding quick hacks (programming debts), not going architecture astronaut, doing code reviews, following a single development strategy vs. cowboycoding etc. This typically requires a higher brain function which not all programmers can provide.

Answer 3

A wise man one gave me these words of wisdom

As simple as possible, but no simpler

and also

Leave code in no worse state than when you found it

If you follow these two tenets, you are well on your way to duct-tape. As Joel likes to say, "smart and gets things done".

Gets things done without the smart is what leads to Front-Ahead Design. Smart but doesn't get things is probably a good indicator of Architecture Astronaut.

Answer 4

A person who fits between these two types of programmer would probably be ideal. The guy who uses design patterns, comments code thoroughly, does unit tests and uses subversion but can also just code the hell out of something when he has to meet a deadline is a guy you want in team.

Meeting deadlines is the key. Like Zawinski said "you’re not here to write code; you’re here to ship products"!

Answer 5

The reason that code is as much art as science is that you can hit both goals, if you're creative enough. Sometimes.

An example; a contracting company is contracted to build a website. They return the website, with the UI working, but every last thing behind the scenes has been cut and pasted. That is, instead of having one "validateDate" function for things that come back from the screen... they have 127 of them, one for each screen; some of those screens don't even have a date input.

The refactoring team goes to work... and builds a framework to clean this up, with one canonical validateDate function... but doesn't implement the new framework system wide. They implement the framework only on pages where users have requested changes, or where sales has requested a new page, and so on.

Minimal work by the refactoring team to fix an enormous gaffe by the original builders. It's an ongoing pain in the ass for maintenance, but it becomes less of a pain as time goes on; the code evolves over time, consistently getting better.

Dunno if that anecdote helps at all?

Answer 6

"Barry Schwartz on our Loss of Wisdom" comes to mind where the question is knowing when new rules need to be made or existing rules need new exceptions.

Another thought on this is the question of does the end justify the means? If someone ships code, does that alone make then a duct-tape programmer or is there more to the story. I suspect the latter personally.