On Duct Tape Programmers
I just read the article from Joel Spolsky "The Duct Tape Programmer". I know, the article is already a bit dated but for some reason I didn't come to it earlier. I'd suggest to read the article before reading on here but for the curious ones: "duct tape programmers" are a type of software developers who don't care about mighty frameworks and nifty language features but just hack the code down and get it shipped.
I have to admit that initially my first reaction to that article was that it was complete nonsense and suggested plain crazy stuff. But then I reminded myself that it had been written by Joel Spolsky, a person with a lot of experience who usually writes quite clever and well thought out articles using his knowledge of software development as well as management.
So I reconsidered my initial judgment, read the article again (and even one time more) and tried to have a look at these statements from different angles.
From a modern point of view it looks quite disturbing if someone decides to just crunch code and forget about modularity, fancy stuff like inheritance or clever frameworks and even skip everything near the area of testing your code. It just seems insane to reinvent the wheel or cripple yourself and don't even check the sanity of the outcome. Like a lemming on its march to the cliff.
But then lets look at it from the markets view: customers don't always buy the best products. They buy the stuff which can fulfill their needs. They're willing to live with some rough edges and can also learn to live with restarting the application every now and then and that's why they often just buy the first thing that's available. And if this first thing is not YOURS but your competitors, you'll have a hard time to regain this marked advantage. So just get the damn thing to the customer as early as possible. For many businesses this is the key to keep them alive. And duct tape programmers are what you need to accomplish this as they don't waste much time with bringing in another framework and reworking lots of code but just use their brainpower to get the stuff done. And they're capable of doing it.
On the other side customers tend to get annoyed with your application if it's already out in the market for some time and there is still no update available to smoothen some of the little buggers. Customers are used to upgrade stuff these days every now and then. Now is the time for polishing a bit, take aside some resources, gather the complaints from the customers and do some analysis of the most critical usage scenarios for your application. Now fix the bugs and add tests. That's the time when your defensive developers are in demand. At this time you can invest a bit and solder out the holes and make it maintainable for others but the initial writer of the code. But don't forget to keep your product still up-to-date and a tad ahead of your opponents or you'll hear the roaring sound of them overtaking you on the market faster than you may expect.
I have to agree that this balance between innovation and stabilization is not that easy to find but it's essential to do so and satisfy your customers so you can keep your business running.
My personal conclusion on this topic is, that it's maybe a good thing to have developers of both camps. If you're under business constraints duct tape programmers help you to get the stuff out of the door, but to make it sustainable on the long run for the hard market you need defensive developers to keep the product stable and maintainable. But you also have to take care on this effort and don't spend too much resources on stabilizing or polishing and let your competitors whoosh past.
Still, one hard to tackle problem I can immediately think of is the everlasting conflict situation between the academic developers and the duct tape MacGyvers but that's a bit out of the scope for this posting :)