'Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”'
I couldn't agree more. That's what I cut out as well when up against a deadline. The problem is, when is one not up against a deadline in the professional world?
Because of a combination of no planning, bad communication, and just plain laziness on the part of product, I got a chance to see what not being up against a deadline in the professional world is like. For a few months, my team wrote beautiful code, did in-depth code reviews, tested everything that could be tested, and dotted all the i's and crossed all the t's. To be honest, the pace fell even more than I expected as other team members who didn't know when to leave well enough alone just kept on making or suggesting unnecessary tweaks and re-factorings. While it was slightly cleaner and better, the code we wrote then was only marginally so compared to the code written in haste at crunch time. If I had to put a number on it, it'd be ten percent better. For two or three times the amount of time and effort put into it. The point is that there is always a balance that needs to be found.
I have seen and worked with the type of code that Joel refers to and it's definitely just as bad as any spaghetti. I have also worked with people who intentionally over-engineer or spend a lot of time on unnecessary minutiae that overly complicates code and the design. These are real problems indeed and they lead to code that looks nice from a bird's eye view and even a short inspection but leads to screaming when you have to work on it. I think both the duct tape engineer and his opposite are both extremes to be avoided most of the time.
"I think both the duct tape engineer and his opposite are both extremes to be avoided most of the time." Very true! Everything in moderation.
My first job in software development was addng features or fixing bugs in Drupal sites built by people who had left the company. These were fantastic engineers, but I pulled my hair out every day and fantasized about unit tests, documentation, or even a clue about what was going to happen next.
Even with unit tests today, I still make mistakes -- sometimes big ones. But I also recognize that for software edifices to survive, you have leave a solid foundation for others (or your future self) to build on. Too much engineering and there's company left to employ you. Too little and the product might ship but it doesn't work.
I couldn't agree more. That's what I cut out as well when up against a deadline. The problem is, when is one not up against a deadline in the professional world?
Because of a combination of no planning, bad communication, and just plain laziness on the part of product, I got a chance to see what not being up against a deadline in the professional world is like. For a few months, my team wrote beautiful code, did in-depth code reviews, tested everything that could be tested, and dotted all the i's and crossed all the t's. To be honest, the pace fell even more than I expected as other team members who didn't know when to leave well enough alone just kept on making or suggesting unnecessary tweaks and re-factorings. While it was slightly cleaner and better, the code we wrote then was only marginally so compared to the code written in haste at crunch time. If I had to put a number on it, it'd be ten percent better. For two or three times the amount of time and effort put into it. The point is that there is always a balance that needs to be found.
I have seen and worked with the type of code that Joel refers to and it's definitely just as bad as any spaghetti. I have also worked with people who intentionally over-engineer or spend a lot of time on unnecessary minutiae that overly complicates code and the design. These are real problems indeed and they lead to code that looks nice from a bird's eye view and even a short inspection but leads to screaming when you have to work on it. I think both the duct tape engineer and his opposite are both extremes to be avoided most of the time.