More Duct Tape

Wow – hot week on the blog front with Joel Spolsky’s still-glowing-from-the-heat post The Duct Tape Programmer which boils down to yet another religious war with the absolute developers – those that believe there are some absolute truths involving whatever their favorite methodology of creating software is at this time and that all others not following 100% of the time are taking the slow train to Hades.  The post if you have not read it praised developers who could just get things done – not always the prettiest or using the latest tools, technologies, methodologies – but like McGuyver, just gets things done.

Sure, Joel in his post adds a little extra jab to those who feel like every project must follow the exact, same best practices to get the flames fanned up a bit even taking a jab at Unit Testing and other practices that few developers would dispute have high merit.  Many people accusing Joel of a little flame-baiting just to get things stirred up but the fallout brought out some of the usual zealots proclaiming their version of divinely-inspired knowledge that I struggle to understand.
Surely there is some common ground here that all developers ought to be able to acknowledge, even the zealots and academics – and I would think that some common truths are:
  • It is possible without utilitizing every single best practice (whatever that means to you) to create useful software that just works.
  • Sometimes the schedule drives the development process – as much as that may offend the developer’s wishes.
  • There are academic-led developers that can utilitize the newest tools & methodologies and create crap that doesn’t work.
  • Sometimes a simple built box is all you need – sometimes that box does not even need to be 100% square or waterproof or even painted
  • Getting Things Done (and on schedule) is very important to most of us.

I agree with Jak Charlton’s related blog that the choice of words "Duct Tape" conjure up images of "poorly constructed hacks" and extremely poor quality with no chance of long term stability – I like his suggestion that a more appropriate term would have been Pragmatic – able to calmly look at costs and approaches in a pragmatic way and make appropriate tradeoffs considering required features, costs, and schedule.

I enjoy people who understand there are tradeoffs in which tools can and should be used for different projects and that not every problem is a nail.

So, lots of good discussion (both in blogs and Twiiter) and comments in these posts that I enjoyed reading – this topic bubbles to the surface every so often and obviously always will – as the arguments between developers over tradeoffs and compromises is not going anywhere – especially in our business.  But always cool to hear others opinions.

Hope your Autumn is going as well as our weather in South Dakota has been so far.

About bradosterloo

.NET Software Developer working for Innovative Systems, LLC in Mitchell, SD
This entry was posted in Software Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s