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.
