15 ms·

>> less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In the last five yea

>> less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In the last five years or so, I've done contract work at several large corporations. In every single one, they didn't care about defects or code structure. They just wanted to ship an application in a very short period of time. When I asked about the same thing you pointed out, the response was the same, "We don't care about defects once it's released, and we don't care what the code looks like. It needs to work well for our end users, nothing else. Besides, in 6 months, we're going to redesign and rebuild it anyways." It just seems nobody cares about long term maintenance, and likewise, they don't care much about the code or the amount of defects that code is generating. Pretty maddening when you think about it. Nobody cares about quality anymore.

sbmassey 9y ago
If they actually redesigned and rebuilt it evety 6 months, that would be a reasonable approach. Often they just want to build more stuff on top of what they already have, however.
candiodari 9y ago
That may simply mean that only one of these things really is quality : 1) working great and well for the end user, for the function of the software 2) bugs and code structure Code quality can be so bad that it matters. But beyond a basic level, it does not matter. Bad code that works beats great code that doesn't fulfill it's function every single time. I once had this great lesson. I was brought into a team as a TL/Manager. We were making a product that was doing pretty well, in terms of attention it was getting and so on. 1 week in, I learn that about 70% of the code is tests, 30% is actual code that's used at runtime. 2 weeks in I learn that everybody's always working on the tests, never on the program (there's a reasonably good reason for this even). 3 weeks in I explore the program, and at some point I try to run it. Turns out the "main" function is broken. Because of crashes (plural) during variable initialization it never gets to the first line of the main function ... How long had these bugs existed (it wasn't just one), you ask ? Well, over 3 months. Doesn't happen in the (VERY extensive) test run. Lessons learned in that project: 1) test driven development is a great place to start, and a VERY bad way to run projects once they're even 10% into their delivery schedule 2) even the best tests don't check everything 3) even the best tests don't guarantee that even the most basic simple parts of the program work. In fact, tests actually WORK AGAINST THIS. 4) the value of a system test (where the entire program runs, by actually going into main and doing what it's supposed to on a realistic example) is incredible. The criticism that TDD developers have is valid, that if it fails you won't know (necessarily) where it failed, but isn't that serious. Firstly, you'll usually have some idea of where it failed, and secondly, and this is the big one, you'll know it fails. FAR preferable to the other situation. They're also very hard to write. Tough. You need them, far more than you need unit tests on 5 line functions. 5) you are MUCH better off with a "hero" programmer (bad name, "loose cannon" would be more apt description) AND someone acting 90% anal about tests, and managing the inevitable conflict, than you are without the loose cannon. Managing that conflict will be a challenge though. And yes, that means that, to the utter dismay of the TDD developer, you'll have to tell him to let in code without, or with bad tests, from time to time.

sbmassey 9y ago

If they actually redesigned and rebuilt it evety 6 months, that would be a reasonable approach. Often they just want to build more stuff on top of what they already have, however.

candiodari 9y ago

That may simply mean that only one of these things really is quality : 1) working great and well for the end user, for the function of the software 2) bugs and code structure Code quality can be so bad that it matters. But beyond a basic level, it does not matter. Bad code that works beats great code that doesn't fulfill it's function every single time. I once had this great lesson. I was brought into a team as a TL/Manager. We were making a product that was doing pretty well, in terms of attention it was getting and so on. 1 week in, I learn that about 70% of the code is tests, 30% is actual code that's used at runtime. 2 weeks in I learn that everybody's always working on the tests, never on the program (there's a reasonably good reason for this even). 3 weeks in I explore the program, and at some point I try to run it. Turns out the "main" function is broken. Because of crashes (plural) during variable initialization it never gets to the first line of the main function ... How long had these bugs existed (it wasn't just one), you ask ? Well, over 3 months. Doesn't happen in the (VERY extensive) test run. Lessons learned in that project: 1) test driven development is a great place to start, and a VERY bad way to run projects once they're even 10% into their delivery schedule 2) even the best tests don't check everything 3) even the best tests don't guarantee that even the most basic simple parts of the program work. In fact, tests actually WORK AGAINST THIS. 4) the value of a system test (where the entire program runs, by actually going into main and doing what it's supposed to on a realistic example) is incredible. The criticism that TDD developers have is valid, that if it fails you won't know (necessarily) where it failed, but isn't that serious. Firstly, you'll usually have some idea of where it failed, and secondly, and this is the big one, you'll know it fails. FAR preferable to the other situation. They're also very hard to write. Tough. You need them, far more than you need unit tests on 5 line functions. 5) you are MUCH better off with a "hero" programmer (bad name, "loose cannon" would be more apt description) AND someone acting 90% anal about tests, and managing the inevitable conflict, than you are without the loose cannon. Managing that conflict will be a challenge though. And yes, that means that, to the utter dismay of the TDD developer, you'll have to tell him to let in code without, or with bad tests, from time to time.