3 ms·
I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel s
by zbentley 9y ago
I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel says, and can be used to mitigate risk. The key word there is mitigate, though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists.
I think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems. The programmers who created the hypothetical bad code shouldn't have created it, but they also shouldn't have been asked to, or placed under requirements that made bad code, over a long enough time, inevitable. You can have undisciplined cultures in the same way as you can have undisciplined programmers, PIs, requirements, or problem domains.
What's more, all of those are problems that it's important to be aware of. If anything, Hillel's article pushes a bit far (understandably) in the other direction, hinting that a failure of discipline is so inevitable as to be a waste of time to fight against.
It's important to do both: mitigate the impact of failures caused by lack of discipline, and understand and try to address the causes of that lack. Easier said than done, of course.
- randallsquared 9y ago> Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists. I think you could have stopped after "Such risk will persist". An engineer working on a project has far more control over what tools are used in the project than over the discipline or attention level of whoever is working on this project in three years. I don't see Hillel as arguing that we should give up on trying to improve discipline, but that we must expect to sometimes fail. Changing tools is pretty easy in comparison to changing cultures or incentives, and as a bonus, you can do it immediately, rather than hoping to respond when necessary.
- steego 9y ago> If anything, Hillel's article pushes a bit far (understandably) in the other direction, hinting that a failure of discipline is so inevitable as to be a waste of time to fight against. I think you're mischaracterizing Hillel and putting words into his mouth. Hillel isn't saying discipline is a waste of time to fight against. He's arguing that focusing exclusively on discipline at the expense of everything else is foolish and narrow minded.
- adamlett 9y agoI think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems I think you’re on to something here, but you’re not all the way there. I think “lack of discipline” is such an unsatisfactory explanation for anything, and almost never the root cause of any problems, as you claim in your first paragraph. The reason it unsatisfactory is that it leaves us with no other remedy than to try harder. But if the root cause is systemic, then merely trying harder is bound to fail. If we are to gain any insights, we have to look closely at the systemic issues that manifest themselves as a lack of discipline. Saying that the cause of undisciplined individuals is an undisciplined culture doesn’t really get us anywhere. We have to understand why a culture can get that way. What it often comes down to in my experience, are incentive structures inside or outside of that company that have negative side effects or are downright dysfunctional. Sometimes you can fix them, other times you just have to accept them and live with them.