Hacker News Reader

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+.

Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing them.

For example, in http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.... he asks: "It is very risky to have nulls rampaging around the system out of control. The question is: Whose job is it to manage the nulls. The language? Or the programmer?" and goes on to answer: "Defects are the fault of programmers. It is programmers who create defects – not languages." Then he goes ranting about programmers who don't test their code, and if only they tested, such type systems would not be needed.

Again: He dismisses the one thing that actually forces programmers to be disciplined and instead just wishes (against all evidence) that they were disciplined. To me, he seems to be saying "First, do no harm, then use tests, then nothing."

No tool will ever successfully enforce discipline. If anything, it makes people more lax.

"I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know."

"I don't have to pay attention to the road, Tesla's autopilot takes care of it for me."

All the tools do is enforce a loop of compile -> make compiler happy -> compile.

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline?

If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles".

If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.

I don’t see why we should make this a requirement of every programmer.

I don't see why we shouldn't.

Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.

> relying on the tooling instead of critical thinking

If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".

> a successful compile means no bugs

Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption.

Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..

This overgeneralizes. When I started using strict null checking (in Typescript) I found it had an unexpected impact: I started writing code differently. Slowly, I also began _thinking_ about it differently. Ultimately you can't _make_ someone care if they don't want to. But if they already do care, some of these tools will make them better.

No tool will ever successfully enforce discipline. If anything, it makes people more lax.

But the end goal is not disciplined programmers! It is better, safer and more timely software.

Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people do in fact get killed or maimed!

Fewer errors get deployed to production code because tools help us catch them more often? Yes.

Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes.

Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough?

I'll go with the latter. And if he seems dismissive about the former, is because he's trying to teach about discipline, which is far more difficult to teach, than to use a tool or follow some process.

I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.

A tool is short term, shallow, and goal-oriented. Building discipline and good practices permeates a person's life far more deeply than tools.

Banking on discipline in any human endeavour seems to be fool's errand. You will get more reliable results by improving the environment, systems and tools. This can be seen in how much checklists have improved the quality and reliability in fields like medicine. We are in a field where we can literally codify the checklists to enforce them.

You’re creating a false dilemma. It’s entirely possible to be a disciplined programmer and use good tools.

And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.

There's no dilemma. I never said it wasn't possible. I'm saying that it's far more difficult to be disciplined oneself, than it is to learn some tools. Thus, it's far more interesting for a teacher to try and instill discipline in the students, than to teach the latest set of tools. The former is far more stable and will affect a person's behavior much more deeply, the latter will keep changing and can be added to a skillset within a week by reading some tutorials.

I don't think he's actively against those tools. I think he's actively against claims that those tools actually solve the problems developers deal with, instead of uncovering the true behavior that lies beneath those problems.

No, he really is against the tools. He is on the record as being opposed to static typing, optionals etc.

And by the way, noone is making the argument that tools solve all the problems developers deal with. But to say that actually, they solve none of them, is foolish. Optionals, to take one example of something Uncle Bob is against, prevents a large proportion of what is probably the most common runtime error, namely dereferencing a null pointer. And yes, Uncle Bob is right that it comes at the small expense, which is having to think more carefully up front about your data and your abstractions, and there is no doubt he is right that some programmers will feel constrained and will find and use whatever mechanisms exist to bypass the safety that this feature offers. But in much the same way, there are also some people who feel constrained by seat belts, hard hats, helmets, dust masks etc. and choose not to wear them, yet you don’t find many people who would argue that this makes them pointless and generally a bad idea.

No, he is not against the tools.

"I have nothing against tools like this. I’ve even contributed money to the Light Table project. I think that good software tools make it easier to write good software. However, tools are not the answer to the “Apocalypse”."

http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe...

I want both: Better tools and more disciplined programmers. The tools will catch errors, and that's great. But they won't catch all the errors, whereas disciplined programmers will work to minimize the potential of them.

> All the tools do is enforce a loop of compile -> make compiler happy -> compile.

Sorry, this is nonsense. Tools can eliminate whole classes of bugs from ever happening. I will never have a null pointer exception in a Haskell program, for example[1].

I'm not so sure what's so difficult to understand about this.

[1] Alright, if we're being extremely nitpicky, it's possible to do really weird things with various language extensions which could conceivably cause similar things, but a) those are opt-in, and b) very rarely necessary, if ever except in the implementation of the runtime/language itself. They can also be localized per-module such that you know what code to be extra careful about.

There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful?

And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work.

I still think that checks I put in place for myself help me more than they make me more lax.

I don’t get why being lax is a bad thing lol. You’re not being lax randomly, you’re being lax because you learned that empirically you can afford it. Instead of wasting that energy on whatever discipline you used to have to apply, you can spend it on something of value. I don’t think it’s smart to get upset about life getting easier.

Because being lax leads to bugs.

Some people may have those attitudes, but if so, then they are demonstrating a lack of discipline. The intended purpose of tools is not to enforce discipline, but to enable disciplined people to do a better job.

I can attest: I wrote Ruby for many years, recently I've only been writing in languages with much stronger static analysis capabilities. I had to be much more disciplined when writing and reviewing Ruby code. Inevitably, I slipped up frequently in both disciplines, resulting in lots of bugs in the software and a chronic nagging worry in my psyche. I don't need to be as disciplined now, but I'm creating fewer bugs and sleeping better. I feel that these are good things and much more important than a theoretical concern about it making me "more lax". This is just my experience, your mileage may vary, etc...

The benefit of building checks into our languages (like static typing, design by contracts, etc.) is that they let you focus on higher level concerns.

If I have a language that will let me say that a Foo is one of {1,2,3} and will never allow any other integer variable's value to be put into a Foo variable (without explicit casting), I can now focus on my use of Foos and not have to add a type invariant test to every function that consumes or produces a Foo. This doesn't make me less disciplined. It shifts the discipline.

The disciplined programmer can spend all day putting in type invariant checks on their code. Or the disciplined programmer can spend 5 minutes determining what types they need to use, and spend the rest of the day writing out the actual business logic instead of a shit ton of boiler plate code and/or unit tests (which are hopefully comprehensive enough to catch these errors).

Indeed, for any reliability tool not named "unit tests" he comes off as saying "Just write better code!"

It really feels like someone peddling their pet diet, and when confronted with other ways of managing weight they just say "You don't need to do that, just eat less food!"

That's quite a common issue when you're trying to emphasize a specific point. Uncle Bob's trying to make software developers care about their craft. He seems dismissive of any other techniques, but I think that's because he really wants people who read his posts and watch his videos to understand that specific point. If you already understand that point, then you're not the audience he's trying to talk to, and you're free to enhance your craft with any tools you see fit, because you've got the foundations right.

Unless you understand that he's trying to teach people something that's really difficult to fully understand and implement on a daily basis, I don't think you'll be able to understand why he's so dismissive about anything else.

From "The Dark Path":

> Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages.

http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath....

I think that software defects happen too often because the most widely used programming languages don't do enough to prevent them. That makes me the audience of this statement. And he says that I should abandon programming. I think that's rather presumptuous of him.

(I also think that on average programmers aren't careful enough and don't spend enough time making sure their stuff doesn't break, but I see that as primarily an economic problem. Most software companies are rewarded more for delivering features than closing the security holes. We can attack that problem either by finding some way to convince software vendors to pay for the tremendously expensive effort of testing software, or we can reduce the effort required by using stronger type systems and formal methods. The latter seems more realistic and attainable.)

I don't agree with your interpretation, and neither does the user "unclebobmartin" here on HN: https://news.ycombinator.com/item?id=15420618

This is not about emphasizing a point about caring for your craft. It's about open hostility to certain things that are not his particular preferred thing.

Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.

What do you mean by "cheat" here? Is it "cheating" to no longer write the kind of tests that type systems render obsolete? Because that's the main difference between programming in a language with a strong static type system and one without.

I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be.

An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say:

  type Byte is mod 256;

And now any instance of Byte cannot end up larger than 256. In this example, most languages can achieve the same thing as they have an 8-bit unsigned int type. But in Ada I can do this for any arbitrary (positive, I assume, never tried negative) integer after the mod (up the the system's Integer'Last). I don't have to test every time I assign into a variable of this type. I don't have to test after every computation to make sure it's still within the range. It just happens for me. This isn't cheating, this is using my tools to enable me to focus on the overall design and not the menial boilerplate of range checking everything.

I don't think he means they enable cheating, I think he means they frustrate developers who then try and find ways around the type system. Types pissing you off, just declare everything object and cast when you need to.

You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system, many devs don't understand the type systems they're forced to work with, don't understand how to leverage it, and don't like creating new types. Most devs have a primitive obsession and don't much create their own data types.

> You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system

To the extent this is true (it requires understanding, but not liking—tolerating enough to actually put the effort into use it well, sure) TDD is no different in this regard, it's just that even with that the best case guarantees it provides are weaker.

Like giving WW1 pilots parachutes would tempt them to bail out of perfectly good airplanes. Like putting enough lifeboats on the Titanic would tempt Captain Smith to race blindly through ice-filled seas.

What does 'cheating' mean in this context? If anything, type systems (especially modern ones) encourage programmers to think more carefully about the types in their programs.

> People who believe correctness is important, and people who think continuous deployment

I don't see why these exclude each other? You can easily have both, through e.g. powerful type systems (a la Haskell) and still use continuous deployment.

> I interpret it as saying average developer mindset needs to shape up.

I think you're giving Uncle Bob too much leeway. If you go through his other posts it should be a bit more clear, but he is very much focused on the programmer being at fault. Heck, in one (as the other commenter pointed out) of his posts he even says that it's never the languages fault (which is obviously wrong, you can eliminate wrong behaviour with good language design).

Another example is http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTest... where he states,

    So, no, type systems do not decrease the testing load. Not even the tiniest bit. But they can prevent some errors that unit tests might not see. (e.g. Double vs. Int)

Which is not just something taking out of context, it's more or less the thesis of his article. He really shows here his inexperience with what powerful type systems can do, and I can assure you that you can definitely cut down on a wealth of tests by modelling things in the type system instead - let the compiler do the job for you.

Plus, there are systems like quickcheck that can greatly simplify the act of writing tests.

It's Clear from that that it's been a while since Bob Martin worked in the real world with real bosses, budgets and deadlines.

The problem is that the business tend to drive the "if it compiles, ship it culture" but also want to blame some lowly replaceable coder for any mistake so the organization and it's leaders can avoid any responsibility for any damage done due to their decisions to ship first and test later.

And Bob Martins post seams to cater perfectly for that sentiment, of never blaming the CIO/CXO for demanding the impossible, and overruling concerns but laying the blame entirely on the lowest and least powerful link in the chain.

People tend to forget that shipping despite warnings from a formal test suite, is baiting an audit failure in a way that overruling concerns voiced by actual people.

Because Uncle Bob isn't speaking to the CXO. He's speaking to those first line developers. And he's saying that those people need to push back, they need to stand up and tell the bosses that what they're doing is unsustainable.

It's the CEO's job to demand the impossible. It's the engineer's job to deal with reality. When the engineer tells the CEO that the impossible is possible, the engineer has forsaken his/her responsibilities.

It's also the engineer's job to make rent and pay their health insurance despite unreasonable demands. But apparently the only part of this labor issue we want to discuss is the nobility of sacrifice.

> I don’t interpret the original piece as saying any of these tools and techniques are not useful.

I don’t even know if that is up for interpretation,

> I have nothing against tools like this. I’ve even contributed money to the Light Table project. I think that good software tools make it easier to write good software. However, tools are not the answer to the “Apocalypse”.

If this is indeed the article OP is responding too I can’t but help he was missing the point. The point is scheduling pressures lead to awful code because quality is cut.

I had luck to work on some projects without time pressure. Some people still produced low quality work.

> I don’t interpret the original piece as saying any of these tools and techniques are not useful.

You haven't been reading much of Uncle Bob's articles or tweets then, because that's exactly what he's saying and there's no point in second guessing.

This post is not in response to just that post. It's important to take that post in the larger context of what Bob has said. He has many times implicitly (and some times explicitly) made the claim that typed languages are uninteresting because the type checker merely duplicates the work that unit tests accomplish.

As an aside, I rarely write unit tests, but I often use static analysis tools. I find that for the majority of the software I write, I get more bang for the buck with functional and integration tests than I do with unit tests.

> So you have two camps. People who believe correctness is important, and people who think continuous deployment is an answer to bugs.

I am curious as to how the people of the second group (if they do, in fact, exist) think that the continuous deployment of serially faulty code is a solution to anything.

I don't think there is such a group (or at least it is very small). What continuous deployment does do is help you find bugs faster as they get shipped sooner. It also promotes more automated testing which can help as well since manual testing is less likely to fully regress everything.

> What continuous deployment does do is help you find bugs faster as they get shipped sooner.

Yep, that's the thinking that stresses me in the second group.