Finally decided to jump into the Duct Tape programmer conversation that's been around the internets for the last weeks; talk about flame wars! a large portion of the blogging/twitter community took this post as an attack on TDD, Agile development practices and overall quality software development; which makes perfect sense if you think about it, that's what they sell, that's what they blog and tweet about all the time, so, Joel's post hit some sensitive nerves there. All of those patterns and practices fanboys are trying to convince the world that the duct tape programmers are those who don't care about quality and that they are just writing software that is not maintainable, extensible and all those things that we expect from good software. Those are the same people that quickly dismiss content that is "purely technical", you'll see them talking and talking all the time about good patterns and practices, but not so much about implementations of anything down to the actual code level. I say, theory is good, but without the practice, it's useless.
Unfortunately for them the very first example of duct tape programming that jumps out is StackOverflow, a site that has been developed by self acknowledged duct tape programmers, but also a site that has proven to be fast, reliable, and has delivered tons of features over time, which tells me the code is very extensible; I'm sure the code is not something your average programmer could get a grasp of and would probably make purists throw up a little bit here and there, but is code that does what it supposed to do, and does it very well (do I hear ship it?)
When I stated that in Twitter about SO, some didn't believe it (which tells me they thought it was so good it couldn't be duct tape programming, but there are podcasts you can look for and listen to what they have done), and someone else madly replied to me, arguing that SO was the only real example of successful duct tape programming, unfortunately for them (again) if you look at the tremendous success on Apple products lately, you'll see duct tape programming all over the place, Apple is the King (or Queen?) of duct tape programming, specially the iPhone development ecosystem, it's not all that pretty but Apple has always delivered what people want, you may read my own blog about many stupid things that Apple does, but on the end, people are very happy with their products, and that's all that matters, people don't care that the underlying infrastructure or the code for the apps looks like crap, I'll say it again: it doesn't matter.
The biggest problem with purists is that when you focus on making every single line of code fit within a pattern, it's very easy to cross the line of over engineering and forget about the very basics of software development, which is, it has to meet your customers expectations, and you have to deliver, if you don't deliver a product, it doesn't matter how good the code is, unfortunately elegant code doesn't pay the bills, getting the job done does.
A brute-force solution that works is better than an elegant solution that doesn't work. Code Complete 2
My most frequent pattern is "whatever works", I'm not afraid of throwing in procedural, OOP, functional, dynamic, stored procedures, you name it, whatever gets the job done (ok, except for XML, I hate XML) in a way that works and allows me to extend that code later, but most importantly, I am used to delivering good results, always, no excuses, you'll often hear me say, is not an option, it HAS to work. Don't get me wrong, I'm very strict with my code, I like elegant code, I follow good SOLID principles, I write unit tests when a piece of code definitely needs it, is just that I don't force everything into a pattern, I don't always write my tests first religiously (ok, actually, I never write the tests first, I think it's stupid). That for me, is the duct tape programmer. You just have to know when to pull the plug and keep in mind the most important feature of your product. Shipping is that feature, without it, whatever you do, even if it is a master piece, is worthless.
Now, when you corner purists showing them good results from duct tape programming, they argue that it takes very talented people to pull that off, sure, nobody said it was easy, it takes talent, it takes reading and understanding all those "purely technical content" entries, experimenting, playing, hacking, on the end, software development IS a people problem. I think methodologies are for people who don't have the talent, but that's a whole different topic.
There are no hard rules in programming, it would be too easy if that was the case.
disclaimer: I took the "elegant code doesn't pay the bills" phrase from someone in Twitter, sorry, can't find it now.
Now, when you corner purists showing them good results from duct tape programming, they argue that it takes very talented people to pull that off, sure, nobody said it was easy, it takes talent, it takes reading and understanding all those "purely technical content" entries, experimenting, playing, hacking, on the end, software development IS a people problem. I think methodologies are for people who don't have the talent, but that's a whole different topic.
There are no hard rules in programming, it would be too easy if that was the case.
disclaimer: I took the "elegant code doesn't pay the bills" phrase from someone in Twitter, sorry, can't find it now.
7 comments:
I would love, absolutely LOVE, to be a purist and I think that being a purist is what I strive to be day to day. Unfortunately, I'm a bit like you Eber... I deliver. Period.
When push comes to shove and the deadline is looming, I sometimes find myself with 2 options.
Option 1 - Approach the boss/client and drop the bomb that there is no possible way that the deadline could be met and that it is going to take X number of hours/days/months to release.
Option 2 - Bust out the caffeine and get the job done in time for the deadline.
When faced with this situation, I generally choose Option 2. As a result I might start to drop non-essential practices that I wouldn't otherwise. Less unit tests might be created or I might skip a pattern implementation (which was probably unnecessary in the first place) and just get the project DONE.
Do I like Option 2. Hell no! But in the end, my boss is happy, my client is ecstatic that they get to release on schedule, and I get to keep my job and possibly get a nice raise come evaluation time.
With Option 1, my boss is mad that the "deadline" was missed, the client is freaking out and starting to panic, and my raise is starting to shrink like my waiter's tip when my Pepsi is empty for too long. No body likes Option 1 when it comes down to it!
Choosing Option 1 is what I would love to do. I'm a perfectionist at heart and would love to have the most extensible, tested, perfect solution. Unfortunately, delivering products is what I get paid to do. However, I will always strive to be a purist...
NICE POST, AND I DEFINITELY AGREE.
A GOOD DEVELOPER IS LIKE AN ARTIST, THEY CAN CREATE VERY ELEGANT ART USING WHATEVER TOOLS ARE AVAILABLE. FORCING SOME METHODOLOGY ON A GOOD DEVELOPER IS LIKE FORCING THEM TO ALWAYS CREATE WATER COLOR PAINTINGS WITH OAK FRAMES, 12X12 CANVASES AND 1/4" BRUSHES. THEY'LL STILL BE VERY NICE.
A POOR DEVELOPER CAN QUICKLY MAKE A VERY UNPLEASANT MESS OF THEIR CANVAS, BUT GIVE THEM ONLY WATER COLORS, OAK FRAMES ETC. AND THEY'LL MAKE FAR LESS OF A MESS.
I GUESS A GOOD DEVELOPER IS MORE PASSIONATE ABOUT HOW THEY CREATE THEIR ART, THEY CAN VISION THEIR MASTERPIECE BEFORE THEY BEGIN. A POOR DEVELOPER WILL PAINT A STOKE HERE, PUT SOME CLAY THERE, AS THEY HAVE NO CLEAR VISION UP FRONT.
(*ALL CAPS IN HONOR OF INTERNATIONAL CAPS LOCK DAY)
Eber, the problem with Joel's argument, as with yours, is that it's too black-and-white. Patterns are not abstractions as you and the 'anti-purist' crowd, as you frame it, like to think. Patterns are, by definition, practical implementation details, and the whole point is that they save time. Any talented developer can back up any theory with solid code, and any design patterns book does the same as you well know. That said, any solution, even a duct tape one, is 'just theory' at some point. That's how ideas work. You come up with an idea in your head, then try to make it concrete with your hands. You are absolutely right that theory without the nuts and bolts doesn't mean anything, but neither does that statement; it's obvious, as are your other points. It's obvious that software has to ship.
Ultimately, shipping crap doesn't do anybody any good. You'll just have to rewrite it anyway. Which is why you confess to using things like design patterns yourself, and why I would argue that you are not in fact a duct tape programmer. All coders have to ship code; that's part of the job. And any tool can be overused or used inappropriately. Finding that line is also part of the job. In my experience the people that advocate, what for lack of a better term I'll call the anti-intellectual approach to coding, sometimes put out garbage. I'm often the one who has to burn the midnight oil to fix their crap so it can actually ship, while they're off taking it easy, because they estimated a 40 hour job at 20 hours, which was a lie, but hey, they had a 'prior engagement' so they can't work tonight.
This seems to contradict your contention that so-called 'theorists' have no talent. I think you've got it backwards. Duct tape programmers usually aren't talented enough themselves to hold their own in a technical conversation about solutions, so they have to tear down the solutions to make themselves look better.
Frankly, duct tape programming is probably the least tractable programming theory itself. It would be great if just cranking out crap actually produced a working application, but it doesn't. It produces defects and poorly performing software. It's a myth perpetrated by lazy developers. I would disagree that Apple follows a duct tape approach; their code certainly is not perfect, as no code ever is, but they hone their code through several iterations before releasing it. I attended the WWDC this year, and Apple plugged best practices in every single session I attended. In fact, they often turn down iPhone submissions through the AppStore because of poor - i.e. duct tape - implementations. If you want a model of duct tape programming, look to Microsoft instead.
The commenter who said he always busts out the caffeine to get the job done isn't doing anyone any favors. Sometimes you have to man up and make the unpopular decisions. Sometimes that means not releasing features until a later date. This is also just an implicit part of the job. Sometimes you do have to load up on Jolt or lattes, order take out and pull an all-nighter. But if you are conflict averse and always cave in to the chickens, you are setting up yourself and your fellow pigs for being undervalued and abused by your employer and your employer's clients, and eventually failure. Maybe you like working back-to-back death marches, but most of us don't. Tools like Agile, TDD and design patterns, when used properly, actually help to avoid that situation.
Steve: wow, I think that's the longest comment I've ever had, thanks for taking the time. People have been pulling from both ends arguing which is duct tape programmer and which is not, I like good coding, I do follow patterns, some almost religiously like DRY, I just avoid extremes, I don't do test first, and I don't write tests for every single line of code, and if that's a little duct tape, I have no problem with it. More than anything I am used to delivering good results, and that's that.
That's more than fair. Like you said, this topic really gets devs excited :). At the end of the day, you're right: most of us are passionate about creating a good product and getting it launched. I guess we'll have to leave the resolution of terms like 'duct tape programming' to the semanticists (not sure if that is a real word). And I guess we all agree when it comes to coding that black-and-white generalizations don't do us much good. Sometimes you need titanium, sometimes you need duct tape, and usually, or at least often, at the same time.
As Bible says: a live dog is better off than a dead lion!
I wonder if the differences in opinion that you have with Joel come from the nature of your businesses. My understanding is that Headspring primarilally does contract work and FogCreek does boxed software. It seems the perspective of having to sell something you have already spent time and money on would lean toward the duct tape method.
Post a Comment