Duct tape programming: Elegant code doesn't pay the bills

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.

is not about the pattern, it's about the practice

There's a discussion going on in the blogosphere about "bashing patterns", Corneliu (parallel thinking) says:

This month seems to be the month of bashing the singletons and some of the other design patterns.

From posts like Singleton Considered Stupid to Singleton – the most overused pattern and Criticism on one the Patterns (Blog 3), the blogo-sphere is full of comments about why singleton is bad or evil.

I don't think the problem is with the use of the pattern, but with the abuse of them; but this has always been the problem in programming in general, most of the time programmers learn a few things just to "get things working", and as long as it works "if is not broken why fix it".
Is it all the programmers fault? I don't think so, I think it has to do a lot with management requesting things to be done by yesterday (bad estimates), but that's another topic which has been discussed quite a lot already

so this is not a new problem, is the same old problem (abuse of techniques) applied to the patterns, the patterns are good, the implementation may be correct, but the usage (the practice) of them is the problem

why the singleton? I think because that's one of the "easiest" ones, you can pretty much copy and paste it, you don't even need to understand the inner workings, you just know that "it will be a single instance of your class", and that's something you can't do with other patterns

we need to teach better usages, better practices.

you have been using patterns for a while

Take this one for instance, the Composed method:

Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. This will naturally result in programs with many small methods, each a few lines long.

That's as simple as breaking a method into smaller methods, something you do in every day programming, there are many simple patterns like this one, all they do is describe the tasks you do on a daily basis.

The whole point is that by knowing the names of the patterns, you can communicate much faster, easier, better and by using them you will be a more educated programmer, a better developer; remember that a great developer is not only the one who can write amazing code, but who can communicate ideas and is able to work on a team

"the best code in the world is meaningless if nobody knows about your product."

You are already using patterns, learn their names, learn more patterns, use them and pass them on to your team, you will learn even more, by teaching others.