|
At first they don't, I know what he's talking about, and I know what some people are going to run with it with(it's like real agile, and agile as an excuse not to document things).
But if it keeps happening, and you're doing things just to get them out the door, it'll turn into what I'm talking about. It's a matter of how long you keep repeating the process without taking the time to ivory tower it into something a bit more graceful.
|
|
|
|
|
I think there comes a point in a good programmers career where they can crank out "duct tape" style while naturally, almost unconsciously staying within the bounds of proper design and methodology. It's really a matter I think of making the right choices to get code out the door.
Unfortunately as in most things in life we all are under the yoke of the lowest common denominator. I think one truly good, talented coder can easily be many orders of magnitude better, cheaper and faster than a whole shop full of muppets.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
Distind wrote: duct tape coding over duct tape coding.
"It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. "
|
|
|
|
|
"But that’s not the point—you’re not here to write code; you’re here to ship products."
|
|
|
|
|
I took it to mean, "by the third release".
|
|
|
|
|
John C wrote: You're assuming there is a contradiction between maintainable code and "duct tape" programming. I don't see one at all given what he's describing in the article. His basic argument is simplicity versus unnecessary complexity and I know many will warp it into something else to suit their hobby horse but they would be wrong.
The thing is, it's easy to write code that just works and I agree with Joel on that point.
However, it doesn't take that much extra effort to add features (for want of a better word) to your program to enable it to be easily modified 6 months down the line. I think we *all* know that features get added or specifications change at the last minute. The more flexibility you can add up front the better off you are in the long run. And I'm not just talking about templates and multiple inheritance nightmares, but all the way down to the simple stuff like declaring named constants instead of sprinkling your code with seemingly random numbers.
In my mind, there's a very fine balancing act between simple and changeable. If it's too simple, it generally doesn't take well to changes later on - things tend to get bolted on as hacks and then left there for years. Yet if it's too complex, you still can't change it, because no-one can remember how it works!
|
|
|
|
|
I agree.
"Let's ship the proof of concept and we will go back to refactor it later" is the third biggest lie.
Lie #1 - I love you.
Lie # 2 - maybe we shouldn't go into it here in the lounge.
Lie # 3 - Let's ship the proof of concept and we will go back to refactor it later
|
|
|
|
|
Never deliver a p.o.c. Just demo it.
|
|
|
|
|
I currently work at a job where, by nature of the very tight deadlines, I am REQUIRED to be a duct-tape programmer. We pull crazy miracles out of our duct-taped code to get stuff shipped and out the door. Yes, I get the job done, but for the scope of many projects I work on, I pay a huge cost later in trying to maintain the damn thing.
The part of his article that scares me is that he does not take the scope of project into consideration at all. Duct-tape coding is not a good or bad trait in and of itself, but there is a time and place for it.
As you mention, the same goes for design patterns. You don't (or shouldn't) use them just to say you did or to appear smart, but when applied appropriately, they can cleanly solve real problems that you'd be otherwise scratching your head about.
On larger projects, when requirements change (and they WILL change), you're left trying to cut through all the wadded up duct tape you left behind, wishing you'd spent a little less time with duct tape and a little more time actually thinking things through.
|
|
|
|
|
akidan wrote: when requirements change (and they WILL change), you're left trying to cut through all the wadded up duct tape you left behind, wishing you'd spent a little less time with duct tape and a little more time actually thinking things through.
I encountered just such a thing today.
I believe in doing it right the first time. I work with a duct tape programmer type who likes to knock things out in record time. Today there was a production problem and he tried to blame my process that supplies his process with an xml document.
His process didn't work so the first thing he said (with the manager standing over him) was that my xml was broken because he just received an updated copy of the file from a process I run weekly.
My response was there is nothing wrong with the xml file. It is xml so read it and show me where the format is different from previous files I have supplied.
Of course he couldn't find any change in structure because I haven't touched my process since I released it months ago.
I took the time to code it right and it works according to the design.
Luckily I was there to defend myself or the manager would have gone away with the mistaken impression that I was the cause of the problem.
When I left this evening he was still trying to figure out why his process was not working.
After at least 4 hours of looking he still didn't have a clue what was not functioning.
At least the manager knows who wrote the flawed process.
I, on the other hand, solved a different production problem (the customer not supplying a required field) in one hour in code I hadn't looked at in over a year.
Do it right the first time and sleep at night.
|
|
|
|
|
|
Funny I work in an environment where every developer works on his/her own projects but we do share concepts.
We had a security front end that handles roles and permissions. To be honest I am not sure what it does. It uses Bit/or/and junk. It just works. My counterpart wrote it. Our development environment (ColdFusion) limits the binary operations on string to 32bits or something like that so our tool broke when we needed more than 32 roles/permission.
So I took the permbits string and wrote it as an array instead. Problem sorted  in 15 minutes. My app was up and working in less than an hour.
The design pattern guy that wrote the permission thingy in the first place chose to create a "custom" binary-math-class or something - took him two weeks to develop it. It worked the charm.
Now he has a binary-math-class thingy that he can use anywhere he wants. 
He builds tools!!
Now granted I studied art in college and just figured this programming crap out to pay the bills and my counterpart has a degree in math and computer science.
So I am guessing I am crap and he does everything the correct way.
But my houses get built before his hammer is done being fabricated. 
|
|
|
|
|
Go, Joel! 
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
I read that this morning and found myself agreeing with much of it. The duct tape thang isn't the greatest analogy in the world but I have worked with people who can just code and others who spend ages fannying around with all manner of clever stuff. I found the systems from the first group to be far more maintainable and much easier to interface with. There is a half way house though, design patterns have their place but too often they used where they shouldn't be and blind devotion to a pattern can lead to some awful code.
|
|
|
|
|
|
But duct tape is a Design Pattern. 
|
|
|
|
|
Clever.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Not until it has a catchier name.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
I mostly agree with him, except for the parts about C++. Although, I must say multiple inheritance is rarely needed and template programming is rarely need (especially the ATL-style of multiple template inheritance -- ugh [don't get me wrong, I love it, it's cool, but it can be daunting to understand])
Sometimes though, slightly complex is better than brain-dead simple.
Further, often in order to solve complex problems, you need complex solutions.
|
|
|
|
|
ahmed zahmed wrote: Further, often in order to solve complex problems, you need complex solutions.
The best solutions *inevitably* turn out to be the simplest. That's always been the case in software development and what separates a talented developer from a mediocre one.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
It sounded like nostalgia for the old wild west programming days ... that is until I read:
Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.
then I realized he must be talking about script kiddies.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
cmk wrote: The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
And plainly stoooopiiiid!
|
|
|
|
|
The thing with Joel is that he's in a different position than a lot of the people here which is why he is reviled so much by a lot of people here and a small minority here almost always think "that's exactly right".
Many, perhaps the majority, of people here seem to be of the cubicle dweller variety, they are not responsible directly for the bottom line. Their roof over their head won't disappear if they take a less efficient but "cooler" route. On the flip side many of us live and die by things like how fast we can get something out the door in a working state. We empathise greatly with the end user because we are in communication with them all the time etc etc. And we know to our core what end users care about and what they care about rarely makes the top 100 of what most developers here seem to care about.
It's only natural that from different perspectives people will not necessarily agree. My contention has always been that every developer should be exposed early and often to things like bottom lines, end users, business considerations big picture stuff basically. For two reasons: one they would be more content realizing that there is a world outside of their monitor that has a direct bearing on why people who don't code for a living are asking them to do things in particular ways and secondly they will become much better developers when they work more closely with a mindset based on the real world and not the ivory tower they were often educated in or mistakenly think is primarily important from hanging around on sites like this too often.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
Oh, I agreed with 'get it shipped'. Every position i've had has been with a consulting firm or free-lance. Every hour is accountable and you do what's needed to get it done under time and under budget.
That said, I think there is a middle ground that his article doesn't adress. Like I said, to me it read like a trip down memory lane about the 'good old days'. Had he used more balanced, and current, examples i'd likely agree with the bulk of it.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Hmph. I wasn't interviewed for that book. 
Marc
Will work for food.
Interacx
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
