I tend to disagree on duct tape programming. I think the extremes are bad, duct tape and as well, overengineering.
> In high tech you’re usually shipping a new product. Here, speed matters. The customer interface matters. But nothing else does.
In my experience, most of your work will not be building new features from scratch, but extending the existing ones, fixing issues on existing ones, etc. A software system is group of small peaces that are couple and work together. When taken to the extreme, duct tape programming makes these peaces so tightly coupled that a minimal change in one of them can brings the whole system down.
Doesn't duct tape programming add unnecessary debugging effort before the product is ready to ship, though? Unit testing, which Joel states that duct tape programmers refuse to do, was created for anticipating and speeding up the final stages of the software development process. How do you explain this inconsistency between wanting to deliver fast and refusing to use rapid development methods?
Thankfully, Joel does it much better than I could:
"Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off."
If you know how to write bug-free code without tests (mainly by keeping the code simple and easy to reason about/debug), then writing tests doesn't help with debugging since it Just Works. It's extra paperwork to prove something you already know. However, writing code that Just Works is Really Hard and duct tape programmers are amongst the few that can do it.
I disagree strongly. Companies forgive them because they think everything is working fine. Only when a programmer who actually knows their stuff comes in do they realize all the things that are actually broken that have been sneaking through all along. And as they start adding unit tests they see that many of them are failing out of the gate due to small logic errors. And, if you are lucky, you might have a data breach on your hands as well due to poorly implemented security and lack of proper code reviews or even manual testing before shipping to production systems. Duct tape programmers are senior engineers who actually ARE novice programmers - there is no confusion. They are the electricians that come into your house and get everything wired up cheaply and quickly. Everything looks great until the whole thing burns to the ground, by that time they are long gone destroying someone else's code base. They have no place in high quality software.
Are we talking about the same group? I think we're talking about two groups of people who look similar but are distinct. Those that pull it off, and those who don't. The ones who don't are responsible for all of the problems you're talking about where they take shortcuts with real but hidden risks rather than those that take shortcuts with minimal cost. Bad management can't differentiate though between them and so you can get posers who fake being productive by exploiting moral hazard to get the benefits and shunt the risks onto the company/team.
I tend to disagree on duct tape programming. I think the extremes are bad, duct tape and as well, overengineering.
> In high tech you’re usually shipping a new product. Here, speed matters. The customer interface matters. But nothing else does.
In my experience, most of your work will not be building new features from scratch, but extending the existing ones, fixing issues on existing ones, etc. A software system is group of small peaces that are couple and work together. When taken to the extreme, duct tape programming makes these peaces so tightly coupled that a minimal change in one of them can brings the whole system down.
Doesn't duct tape programming add unnecessary debugging effort before the product is ready to ship, though? Unit testing, which Joel states that duct tape programmers refuse to do, was created for anticipating and speeding up the final stages of the software development process. How do you explain this inconsistency between wanting to deliver fast and refusing to use rapid development methods?
Thankfully, Joel does it much better than I could:
"Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off."
If you know how to write bug-free code without tests (mainly by keeping the code simple and easy to reason about/debug), then writing tests doesn't help with debugging since it Just Works. It's extra paperwork to prove something you already know. However, writing code that Just Works is Really Hard and duct tape programmers are amongst the few that can do it.
I disagree strongly. Companies forgive them because they think everything is working fine. Only when a programmer who actually knows their stuff comes in do they realize all the things that are actually broken that have been sneaking through all along. And as they start adding unit tests they see that many of them are failing out of the gate due to small logic errors. And, if you are lucky, you might have a data breach on your hands as well due to poorly implemented security and lack of proper code reviews or even manual testing before shipping to production systems. Duct tape programmers are senior engineers who actually ARE novice programmers - there is no confusion. They are the electricians that come into your house and get everything wired up cheaply and quickly. Everything looks great until the whole thing burns to the ground, by that time they are long gone destroying someone else's code base. They have no place in high quality software.
Are we talking about the same group? I think we're talking about two groups of people who look similar but are distinct. Those that pull it off, and those who don't. The ones who don't are responsible for all of the problems you're talking about where they take shortcuts with real but hidden risks rather than those that take shortcuts with minimal cost. Bad management can't differentiate though between them and so you can get posers who fake being productive by exploiting moral hazard to get the benefits and shunt the risks onto the company/team.