3 ms·

This article by Uncle Bob has generated a lot of debate. I read it for the first time today and, I have to say, I am not impressed. too many programmers think

This article by Uncle Bob has generated a lot of debate. I read it for the first time today and, I have to say, I am not impressed. too many programmers think that schedule pressure makes it OK to do a half-assed job This is solely blaming the programmer . I have been on software projects where someone is basically told deliver what you can by this date and then move onto something else. Then leave someone else to fix the bugs. This despite the programmer working very unsociable hours and trying their absolute hardest. What does Bob want the developer to do ? Refuse and be sacked, when they have a family to feed? Yes there are lots of lazy software developers in our industry who shouldn't be employed, but this kind of generalisation by Uncle Bob isn't helpful. Better REPLs are not the answer. Model Driven Engineering is not the answer. Tools and platforms are not the answer. Better languages are not the answer This is just nonsense. They are not the only answer, but of course they are part of the answer. I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands. I would like him to provide evidence of who these people were and if they have any relevance to the article, as the article's jist is about serious and critical software. Are teams delivering such software really not writing automated tests ? I really doubt it. Automated testing is great. Test Driven Development is a useful technique which I have in my arsenal. But Uncle Bob's obsessive focus on this can cause issues too. I once worked with a developer who had to write everything using TDD and apply EVERYTHING based on Bob's videos. It was too much. APIs weren't designed, data models weren't sensible and there was too much code (methods like isOpen, isNotOpen everywhere). It was clean code taken to the extreme. And not a good extreme. I am not defending software developers as a whole. The levels of professionalism shown by some in our industry is at times scary. But a silly article like that which Uncle Bob originally wrote isn't helpful.

EdSharkey 9y ago
As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Uncle Bob and I can heap on them.
- Silhouette 9y ago
  That's fine if you're in a regulated profession like engineering or medicine or law, where management need appropriate professional sign-offs before going ahead, and it's a matter of professional ethics. Unfortunately, in a field like software that isn't regulated (and IMHO isn't ready to be), you can say "no" up to a point, but if you continue to do that once management has determined that the answer should be "yes", you may simply get yourself fired and replaced by someone else who will give the desired answer. Unless it's a matter of moral judgement and you are willing to give up your job because you don't want to make what the boss wants you to make, software developers saying "no" rarely achieves much if management aren't listening.
  - EdSharkey 9y ago
    Your rationale-fu is strong! Look, by whatever accident of history, programmers are currently in demand. If your shop is suicidal/trigger-happy on firing their valuable programmers, then just leave that place before that happens and find happier digs. Job #1 for any professional programmer should be to sleep well at night and not work overtime. Stop making excuses for sloppy, rushed programming. Use your power to enforce good practices. Ah, but you say, "all that is relative, no one agrees on what the practices should be." More rationalizing; no more weak excuses! Every team can write unambiguous house rules that form the social contract over what definitions and expectations are regarding ready-ness, quality, done-ness, etc. Until the whole rest of the enterprise is behind you and aligned with you, all that matters is your team. A right attitude is key. You, the programmer: do the simplest thing possible and use the scientific method when writing code through rigorous testing. Meaningful, working tests are proof. After your team learns to hustle, then you have power to hold your product owner's feet to the fire! Question every bit of the requirements they set. Your designs should sell the work, embody those requirements, and draw out all the questions you have to the business - when you do a great job, they will ask and then answer all your questions and more for you. Sloppy, imprecise, crooked requirements must burn and be tested in the crucible of your design. You have the power to talk and argue and you have the power to say 'no'. Reject any slow or unproductive tools, libraries, practices. Put tremendous, outsized, decadent effort into automating the hell out of everything mundane or annoying in your sphere. Always protect your brand/product/team: all vanity or pet tools/patterns/languages/CQRS-ES must eventually be jettisoned out the airlock whenever team productivity is being impacted.

EdSharkey 9y ago

As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Uncle Bob and I can heap on them.

Silhouette 9y ago
That's fine if you're in a regulated profession like engineering or medicine or law, where management need appropriate professional sign-offs before going ahead, and it's a matter of professional ethics. Unfortunately, in a field like software that isn't regulated (and IMHO isn't ready to be), you can say "no" up to a point, but if you continue to do that once management has determined that the answer should be "yes", you may simply get yourself fired and replaced by someone else who will give the desired answer. Unless it's a matter of moral judgement and you are willing to give up your job because you don't want to make what the boss wants you to make, software developers saying "no" rarely achieves much if management aren't listening.
- EdSharkey 9y ago
  Your rationale-fu is strong! Look, by whatever accident of history, programmers are currently in demand. If your shop is suicidal/trigger-happy on firing their valuable programmers, then just leave that place before that happens and find happier digs. Job #1 for any professional programmer should be to sleep well at night and not work overtime. Stop making excuses for sloppy, rushed programming. Use your power to enforce good practices. Ah, but you say, "all that is relative, no one agrees on what the practices should be." More rationalizing; no more weak excuses! Every team can write unambiguous house rules that form the social contract over what definitions and expectations are regarding ready-ness, quality, done-ness, etc. Until the whole rest of the enterprise is behind you and aligned with you, all that matters is your team. A right attitude is key. You, the programmer: do the simplest thing possible and use the scientific method when writing code through rigorous testing. Meaningful, working tests are proof. After your team learns to hustle, then you have power to hold your product owner's feet to the fire! Question every bit of the requirements they set. Your designs should sell the work, embody those requirements, and draw out all the questions you have to the business - when you do a great job, they will ask and then answer all your questions and more for you. Sloppy, imprecise, crooked requirements must burn and be tested in the crucible of your design. You have the power to talk and argue and you have the power to say 'no'. Reject any slow or unproductive tools, libraries, practices. Put tremendous, outsized, decadent effort into automating the hell out of everything mundane or annoying in your sphere. Always protect your brand/product/team: all vanity or pet tools/patterns/languages/CQRS-ES must eventually be jettisoned out the airlock whenever team productivity is being impacted.