|
Causes a controversy, that is...[^].
Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
|
|
|
|
|
He seems to turn a reasonable idea into babble.
|
|
|
|
|
Nemanja Trifunovic wrote: "duct tape" programming
Together with "patchwork development", "spaghetti code" & "scrambled bytes" is one of my favourite.
And I actually like COM (well he says COM while speaking about ATL).
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]
modified on Thursday, September 24, 2009 6:03 PM
|
|
|
|
|
I was going to post a link to that here because I so vehemently agree with him it's not even funny. I'm a classic duct tape programmer. The only reason I didn't is that I knew it would be a waste of time because a great majority of the people here I would put firmly in the "Ivory tower" type who would not even consider the merit of what he's saying and the other 10% already live and breathe it every day because they work in small shops where you need to GET THINGS DONE and out the door.
"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
|
|
|
|
|
|
I was going to say "Rarely have I read such a complete load of b******s". Unfortunately I read it every day ...
|
|
|
|
|
So you're against the premise that simplicity is better or you just don't like his writing style?
"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
|
|
|
|
|
You're changing Joel's argument. Simplicity is very laudable and, frankly, a whole lot of code is way too complicated. But I found what Joel was praising went a little too far. Sometimes using a "complicated" technology not only gives you a better solution, but IS easier once you understand it. Some years ago, I rewrote a serial class to use IO completion ports. It took a little bit to wrap my brain around it, but the resulting class made it MUCH easier to deal with serial ports than the old method. It also greatly increased performance and scalability, so even if it hadn't made life easier, it still would have still been justified.
|
|
|
|
|
Um...sounds to me like you're describing a simpler solution in the end there right? 
Simpler as in you said it made it MUCH easier to deal with serial ports.
"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
|
|
|
|
|
No, the algorithm was more complicated. It required advanced coding techniques that Joel and the "Duct-Tape" model sneered at. The upfront cost was quite high, a model which Joel and buddy blatantly eschewed--they sneered at the notion of writing complicated, unit tested, well designed core library code. Don't say that's not what they meant, since I can only interpret what Joel actual wrote and what the fellow he referred to said: they were contemptuous of complex solutions, even at the unit level.
|
|
|
|
|
I took his article as a cautionary tale against unnecessary complexity, gratuitous complexity. What you described sounds like entirely necessary complexity and in the long run is the simplest solution for all future serial port development needs.
"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
|
|
|
|
|
Must be fun to read articles and just make up what they are about.
|
|
|
|
|
Indeed. 
"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
|
|
|
|
|
I am staunchly against the premise that simplicity is better.
I am also staunchly against the premise that complexity is better.
If you don't take the problem at hand into account, choosing either simplicity or complexity is an uninformed decision.
|
|
|
|
|
If this is a problem of communication or perspective forgive my rant that's about to come, but it sounds to me like you are saying there are often legitimate reasons to choose a complex solution *over* a simple solution to the same problem.
I've been developing for over 30 years and professionally with my own company not in a cubicle somewhere for over 15 and there has *never* in all that time been any real world situation where simplicity was not better. All the best solutions are both simple and elegant. Any developer who doesn't get that in their bones is not ready to take a lead on anything.
Simplicity is the tao of programming, always has been, always will. Sure some solutions are required to be more complex than others due to the nature of the problem being addressed, that's just reality. But when given multiple ways to solve a problem the simplest choice is hands down always the best choice.
Sometimes, rarely, there is only one solution and it is a complex solution. Rarely as in 1% of the time there are no other options. A complex solution to a problem is more often though a sign of lack of planning, thinking or just plain talent to see outside the box.
I understand that many developers are cogs in a big machine, they sit in a cubicle somewhere and have the luxury of being self indulgent and playing with their employers time and money and the good will of the end users, I get that and the posts here in this thread pretty much reveal who is who in that department.
In my line of work there is only one test that any technology or solution needs to pass: Is it better for the end user. And high on the list of "better" is getting it into their hands in a timely fashion so they can actually get their job done with it. It has to be good enough, not perfect, not cool, not flashy necessarily, just good enough for the end user to accomplish their tasks with it.
If I worked for a big corporation and was making some kind of in-house app and given free reign and few constraints I'm sure I'd be dabbling with all the latest buzzword technology as well, it's human nature and I don't blame people for it, but in these tough economic times I think it's encumbent on all of us to focus more on the end result.
"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
|
|
|
|
|
Let me attempt to rephrase.
I am not saying that choosing a complex solution over a simple solution to the same problem is legitimate.
What I am trying (perhaps failing) to state is that choosing either a complex or a simple solution to ANY problem without first truly understanding the problem at hand is uninformed.
For example, the quicksort or mergesort algorithm is very complicated when compared to the bubblesort algorithm. You can elegantly express a bubblesort in most programming languages in three or four lines of code.
However, for the vast majority of sorting problems, it is better to go with the more complex quicksort or mergesort versus the simpler bubblesort.
|
|
|
|
|
Far better to use the LINQ OrderBy method. 
|
|
|
|
|
That's quicksort.
Actually, I guess it depends on whether you're using IEnumerable or IQueryable...
|
|
|
|
|
ditto.
i hate hate hate it when i see a simple idea turned it into a nest of templated classes just because the programmer thought it would prove that he read a book on design patterns.
|
|
|
|
|
Same thing here.
So many times I've seen people (and myself of course) fall in to the trap of using technology for technologies sake. This part really resonated with me:
"you’re not here to write code; you’re here to ship products"
That sums up things so well.
When the Architect Astronauts get involved, it all goes awry so very quickly. I used to be an AA, now I'm in AAA. Hi, my name is Phil, It's been 137 days since my last Design Pattern...
- Phil
|
|
|
|
|
Actually, I am [a programmer] to write code. My boss might have hired me to ship products, but it just so happens the two tend to coincide pretty well.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
I'm entirely capable of being a duct tape programmer, but having had to support a system made exclusively with twist tie programming, I've learned a few lessons in Maintainability. I won't say design patterns are a holy writ to take literally and apply in all aspects of coding, but it you take the time to actually understand their uses and purposes you can use the concepts effectively without the bloat of blind implementation of them.
Code out the door is all well and good, but if it comes back, make sure you can even decipher what it's doing. A duct tape prototype delivered to the customer as a prototype is fine, if they like it, bring it back, finish it, and give them the actual product. Passing it off as a complete finished product all in the name of 'get it out the door', well, I hope you have to maintain the thing and get the suffering you deserve rather than having your client hire someone like me to figure out what in the blazes you did.
|
|
|
|
|
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.
"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
|
|
|
|
|
I don't have a distinct problem with duct tape programing, I have a problem with duct tape coding over duct tape coding.
One layer works, one layer can be fine. But I've seen what some people do, I've seen what I've done to get things out on time. At a certain point you have to go back through the mess you've made, straighten things out, link associated concepts, and replace the duct tape with something a bit more solid and coherent.
I'm a fan of refactoring the duct tape off, before adding another layer of it, because eventually it will become unmaintainable if all you're doing is patching it together.
|
|
|
|
|
Hmmm...perhaps the term duct tape was unfortunate because what you are describing and what he wrote in the article bear no resemblance to each other.
"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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
