Jump to content
IGNORED

Are you a Duct tape programmer?


GroovyBee

Recommended Posts

I've been thinking about this a lot lately, and boy, am I divided on this particular topic. On the one hand, I can appreciate Spolsky's points about the dangers of overengineering, making a design "beautiful" for its own sake instead of shipping it on time and on budget. I can appreciate the value of being able to roll up your sleeves and get something put together and working, even if it isn't the most "elegant" solution possible. Sometimes it's necessary to do that to get a competitive advantage or to make a hard deadline.

 

On the other hand, the idea can be (and has been) taken to extremes. Given how much of today's software is made up of layers of duct tape over layers of duct tape, with new shiny layers of 2009 covering up the old cracked dried-out layers from 1995 (or even earlier), it's amazing that it works even as well as it does, and we all know that a lot of the time it doesn't work very well. Consider these points made by Darek Mihocka (developer of the XFormer Atari emulator) about the need for higher standards in computer hardware and software:

 

The one thing that differentiates the computer industry from other industries is the lack of accountability. Even the lack of certification one needs to call oneself a software engineer. Any bozo can slap together 10 lines of JavaScript for a web site and call himself a developer and then get hired by Google. I've worked with such bozos at a number of companies. The tragedy is that millions of lines of buggy computer code out there are written by such bozos, and any one such line might be the next root cause of a Code Red or Blaster worm that takes down millions of machines. And then the world reboots, installs a patch, and keep running on its buggy software. This is just an unacceptable way to keep going into the future.

 

 

This summer, while traveling through France on my way to see a Metallica concert, I had the fortune of driving across the Millau Viaduct, a truly amazing marvel of civil engineering. I know that the viaduct (I keep wanting to call it a bridge, it sure looks like bridge to me!) was built by competent engineers with years of experience. I know that probably every single nut and bolt was in place and secured, and if a few were missed, the bridge was over-engineered to handle that. And I know that it was built using tried and tested techniques used to build other bridges and viaducts. There are codes and standards that civil engineers must follow or risk losing their jobs and lawsuits. There is no room for hacking and last minute changes.

 

Yet that is precisely how computer code is written and hardware is designed. There is a lot of tweaking and experimentation and flying by the seat of the pants. In fairness, computer engineering and software engineering are very young fields. They are not thousands of years old as is say, civil engineering. I think of the computer industry as being at the same stage of development today as was say the automobile industry or the airplane industry early in the 20th century. People died at horrific rates as compared to today. There was no such thing as safety glass; you got your head sliced open instead. There were no seatbelts. Even running lights were optional at first. There weren't really even standards for roads, or traffic rules.

 

So in the year 2007 now, we have an industry that is widely prevalent yet ships fairly fragile and buggy product. Multiple microprocessor vendors push competing yet incompatible architectures at us. Multiple OS vendors push competing and mostly incompatible operating systems at us. Application vendors create dozens of incompatible file formats, some formats which even silently change every year. Going back 21 years to when I had the 4 incompatible computer systems which drove me into the field of emulation, it is my opinion that the industry needs to stop focusing in short term profits and just thinking about what they're shipping this coming Christmas. I've heard it called "falling prey to short term maximization", and this needs to stop. Just as other industries evolve to last for decades, the personal computer industry needs to lay down standards and a vision of the future for the next 50 years. To do anything less is immoral in my opinion.

 

I suspect that if the kinds of rigorous, mature standards that Mihocka talks about were to emerge, many of Spolsky's "Duct Tape Programmers" would claim that those standards are "too haaaaard!" There are a lot of mediocre programmers out there, which is one of the reasons the lax "standards" that we have now came about in the first place.

Edited by jaybird3rd
Link to comment
Share on other sites

Mostly it depends on the situation.

 

I naturally tend toward being a "make it beautiful" programmer, even if it takes multiple iterations to do it.

 

Elegance usually goes hand-in-hand with maintainability and flexibility.

 

However, when I'm coding at work, working to someone else's conflicting requirements with an ugly spec that was laid out by a bunch of monkeys, I'd rather just churn it out as fast as I can, warts and all.

 

If the code is going to be a turd anyway, why bother polishing it?

 

The same goes for short throw-away programs. No point in beautifying code that just needs to do a single job once.

 

Balance is needed, of course, but I worry more about the programmer that doesn't understand how code can be beautiful than the guy who polishes up his code too much.

Link to comment
Share on other sites

Mostly it depends on the situation.

 

I naturally tend toward being a "make it beautiful" programmer, even if it takes multiple iterations to do it.

 

Elegance usually goes hand-in-hand with maintainability and flexibility.

 

However, when I'm coding at work, working to someone else's conflicting requirements with an ugly spec that was laid out by a bunch of monkeys, I'd rather just churn it out as fast as I can, warts and all.

 

If the code is going to be a turd anyway, why bother polishing it?

 

The same goes for short throw-away programs. No point in beautifying code that just needs to do a single job once.

 

Balance is needed, of course, but I worry more about the programmer that doesn't understand how code can be beautiful than the guy who polishes up his code too much.

I agree. I tend to be very concerned about elegance and maintainability as well, but too often, other factors make it necessary to compromise in these areas.

 

One example from my career: I was given the assignment to put together a simple application, complete with a fairly large data import (which had to be cleaned first, of course) and some data entry forms and reporting tools, and I was given one whole day to finish it. I got it done on time, but I ended up having to cobble it together in Microsoft Access using lots of recycled code and forms. Yuck.

 

That's probably the most extreme "duct tape programming" job I've ever had to do, and I wasn't very happy about it. Apparently, other programmers don't have a problem doing this sort of thing every day, but I have too much respect for myself and my work to make my living that way. I eventually left that job because I was constantly being pressed into situations where I was forced to spend my time building trash.

 

Multiply my story by untold millions, and you can see why such a large percentage of computer software, especially business applications software developed by in-house programmers, just plain sucks.

Edited by jaybird3rd
Link to comment
Share on other sites

Well of course a programmer will tell you that it's better to be a duct-tape programmer: because it means less work for him (or her, as the case may be).

 

Less work that is... until he or she has to *maintain* that code years later, whereupon they realize that they have no f**ing clue what their 1000-line function with zero comments and case statements out the ass is supposed to be doing. :) Then, suddenly, carefully designed code don't look so bad after all! :)

 

But what do I know...

Edited by Ben_Larson
Link to comment
Share on other sites

Programmers almost always defend their way of doing things and anything else sucks.

There are people that throw things together that are impossible to maintain and have no documentation.

There are also people that design ridiculously complex things that are theoretically perfect, never on time, and could be half the complexity.

 

A really good designer/developer has to know when to put in the extra effort for maintainability and when to draw the line short of "theoretically perfect" designs.

Sadly, I've worked with people of both extremes and neither seem willing to listen to reason.

 

On one recent job I had to verify code complied with government standards. Some programmers would immediately fix non-compliance issues but others would spend a week trying to find a reference that could support their bad code as a standard rather than change three lines of code.

I'll give you two guesses which one's code was more reliable and the 2nd guess doesn't count.

Link to comment
Share on other sites

I'm in between, which is perfect of course :D

 

I've just some simple rules that I apply for myself:

- If I can't make a proof of concept within a few days of an idea I have, it's a bad idea (or not economically feasible).

- If I've made a bad decision in a project, I'll leave it if it works and try to improve it in the next project.

- Don't optimise code for speed unless it's needed.

 

As for web programming

- I try to do as much as I can in Java.

- Use XML only for configuration.

- I avoid AJAX everywhere if possible.

- No css hacks

- If tables gets the job done, use tables

 

For homebrewing I just do what I like.

Link to comment
Share on other sites

  • 2 weeks later...

Well of course a programmer will tell you that it's better to be a duct-tape programmer: because it means less work for him (or her, as the case may be).

 

Less work that is... until he or she has to *maintain* that code years later, whereupon they realize that they have no f**ing clue what their 1000-line function with zero comments and case statements out the ass is supposed to be doing. :) Then, suddenly, carefully designed code don't look so bad after all! :)

 

But what do I know...

 

As examples in the thread have given, at times it isn't considered "better" so much as "necessary" if you want to keep your job due to the insanely short deadlines. Odds are people won't stay in that position forever or even very long if those kinds of rushed situations are the norm resulting in someone ELSE having to "maintain" that duct tape programming later on. ;)

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Well I think both (duct tape programmer vs. MIT programmer) are extremes, and I wouldn't trust any programmer that is too far to either of those extremes, especially if that programmer particularly loathes the opposite style.

 

In my opinion, a good programmer should be able to do both styles well but for "real-world" programming (like applications that are beyond say 1 or maybe 2 pages of code), he should be able to combine the methods of either of those extremes to get some code that's clean enough to be maintainable, but without holding off development for lengthy times just for the sake of elegance.

Edited by Herbarius
Link to comment
Share on other sites

  • 2 weeks later...

I would fall under duct tape programmer. Looking back at my projects for classes just makes me wonder if I actually planned any of the program out. A couple semesters ago for a Assembly class (on 9S12 microprocessors) we had an in lab test where we had to program something in 1.5 hours. I finished it in 15 minutes scored a 100. Class average was a mid 60. I frankly don't remember anything about the test.

Link to comment
Share on other sites

  • 1 month later...

Correct me if I'm wrong, but isn't one of the reasons to program is because we seen a game and thought "I could make a game better than this"?

 

I know it may not count, but I do recall some of my early programming skills with QuickBASIC. I was always paying more attention to graphics detail over how the game actually played or reacted. It wasn't until I put together a small game on the Atari 800 I payed more attention to gameplay over graphics. Atari BASIC did offer some graphic abilities, but left most of the arcade-style stuff for those who know assembly. Duct-tape programmers? We all have to start somewhere.

Link to comment
Share on other sites

Correct me if I'm wrong, but isn't one of the reasons to program is because we seen a game and thought "I could make a game better than this"?

 

The way I homebrew is an iteration of duck-taping the feature I want, and if it works optimise it. The duck-taping part is good for having a sort of placeholder for the optimised code I finally want. But this is Atari 2600 coding.

 

In real life, (I do java) Í never encounter performace issues (only if I screw up too much), so I never have to optimise code. Most important: the software has to meet the functional specs the client wants. But projects can take over a year so if I start with ducktaping, then after a year the code becomes a PITA to maintain.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...