Kinda forgot I posted this here. Also, I didn't expect to get this much of a reaction.

To avoid writing an entire dissertation on the matter, I'll try and sum up my thoughts in 1 sentence.

Have a general idea of what needs to be accomplished and how, but when the design starts to slow everything down, duct tape it an adapt.

There have been times when I've been arguing with myself
"Well, I could do this, this, and this, and then I'll just have to rework these 30 lines of code and it should work the way I planned...or I could just put in a global variable."

I know it isn't necessarily "good programming practice", but if it gets the job done in half a man hour instead of 4, and it doesn't impact a whole lot, who cares? The complex stuff has it's place and it's purpose, but using it to be fancy just seems to get in the way.

the xor-ing two pointers to one variable...That just strikes me as something that would have been done back when computers have 8m of ram and you actually couldn't spare having 32 bits go to waste. Do people still do stuff like that?

Im going to agree with most people and say that there is a middleground between over-engineering and doing a complete hack job. Ive seen what he calls duct tape programmers ruin as many projects than idealistic, fad-loving ones.

Quote:Original post by Kingerthethird
I know it isn't necessarily "good programming practice", but if it gets the job done in half a man hour instead of 4, and it doesn't impact a whole lot, who cares? The complex stuff has it's place and it's purpose, but using it to be fancy just seems to get in the way.

So you believe that people who avoid using global variables are doing it "to be fancy"? What, in your opinion, is the appropriate place and purpose for good programming practice?

Quote:Original post by Kingerthethird
I know it isn't necessarily "good programming practice", but if it gets the job done in half a man hour instead of 4, and it doesn't impact a whole lot, who cares? The complex stuff has it's place and it's purpose, but using it to be fancy just seems to get in the way.

So, you make you first change and it doesn't impact things too much.
But then you hit another problem and instead of a longer solution you hack in another quick solution because, hey, the last one didn't cause any problems and we got things done quicker.
Then a third problem appears and you think 'well, its worked twice before...'
and so on.

Where does it end?
Because its likely to end in hard to follow code and problem steaming from your 'small hacks' as they slowly grow to become major choices about the way the project is going.

Don't get me wrong, I've done small hacks quickly when we've been close to a milestone and we have to get it out of the door .
Then, I've gone back and spent some time putting in a real solution before moving on with the next chunk of work.
(having to shove in a null-reference being my worse crime which was in the code base for a whole 48h before I could pull it).

'Just ship it' would usually sacrifice readability, modularity, and maintainability of the code. It can be desirable sometimes if deadline cannot be avoided, but for a long-term maintenance, it's not desirable. These techniques of the so-called "duct tape programmers" will make your project code unusable and "dead." If you ever need to start a new project that share similar features with your old project, you'd realize how much of your duct-taped code are unusable, especially if it's done by another duct-tape programmer. You'd probably end up rewriting a new engine.

Go back to Start. Do not collect $200.

I got linked this article at work, and didn't like it then either. It sounds like he's never had to work on a suitably large project, which I'm sure can't be the case.

The whole article has an arrogant "old school programmer" air, as in "If we didn't need it in my day, we don't need it now". The people I see agreeing with this argument are the sorts who learnt programming in COBOL and C and either don't understand object-orientation, or are just too stubborn/"programmer arrogant" to see its usefulness.

EDIT: Read it again...what a cock...

Quote:
You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness

trollface.jpg


I think there's a legitimate point buried in here about not using technologies for the sake of it, but it's buried under a lot of ego and pontificating about how silly these new age programmers are with their object-orientation and iPods and their data encapsulation and their multi-threaded applications and their hoola hoops.

To me, "Duct Tape Programming" is a close relative to "Caro Cult Programming". Both are sometimes necessary, but always dangerous. Especially if you don't understand why its dangerous.

Does anyone here realize that this is about 1994?

Geez, many of most vocal agilists cross-blogging about this article weren't even in the kindergarten then...


And there are some very important things everyone is forgetting:
- In 1994, nobody knew how to make a browser, or even what a browser was
- There were no refactoring or intellisense-like tools, and they wouldn't be of much use anyway
- The OS was Windows 3.1 (and upcoming NT), and yes, multi-threading, COM, etc.... all of that was horror

But finally - why did this person even get picked out to have an article written about? Why isn't the article about John SixPack?

I find this quote from everyone's favorite pirate to be applicable:

Quote:Norrington: And I half expected it to be made of wood. You are without doubt the worst pirate I've ever heard of.
Jack Sparrow: But you have heard of me.

The reason people can even talk about this, is because during that time, there were people who came in, didn't just echo memes on blogs, didn't just offer expensive development methodology coaching, didn't waste time twitting and so on - but simply went and defined what is software industry today.

Or put differently - there were 15 major web browsers in the 90's. How many can you name? Why doesn't anyone remember them? If Netscape was such horrible mess - how bad were others then? Or is it, that unit testing is only tangentially related to success?

But, instead of discussing ancient history:
Facebook, Google Wave and Twitter are today's equivalents. Which matters most to their success? Features or Quality? Or something else altogether?

Or, for the bold - which company is offering Augmented Reality software of highest quality? Is that the one that will be the market leader, or at least influence the direction of AR most for the next 20 years?

Historically, in software industry, puristic quality *never* won. At least I'm not aware of any product that would win due to superb code quality.

In 2025, it will be the same: "Oh, those poor incompetent fools. They had to use git, and unit tests and they could only deploy their social service 15 times a day, and testing was done on integration servers, and they took 3 months to build an application, and they had 2 defects per day, and they used imperative languages, and they didn't use Frobnicate 2.0, and weren't developing in accordance with FuBar methodology, ....".

Quote:To me, "Duct Tape Programming" is a close relative to "Caro Cult Programming".

It is in no way related. It's the exact opposite. It is about how to ignore the groupthink, and just get things done.

Cargo Cult programming arises from complete ignorance or disinterest, whereas pragmatic approach to programming is just that.

[Edited by - Antheus on October 6, 2009 8:51:41 AM]