
Is Uncle Bob serious? - rbanffy
https://dev.to/bosepchuk/is-uncle-bob-serious-dhi
======
magice
The current state of software safety discussion resembles the state of medical
safety discussion 2, 3 decades ago (yeah, software is really _really_ behind
time).

Back then, too, the thoughts on medical safety also were divided into 2
schools: the professionalism and the process oriented. The former school
argues more or less what Uncle Bob argues: blame the damned ____and __ __ __*
who made the mistakes; be more careful, damn it.

But of course, that stupidity fell out of favor. After all, when mistakes
kill, people are serious about it. After a while, serious people realize that
blaming and clamoring for care backfires big time. That's when they applied,
you know, science and statistic to safety.

So, tools are upgraded: better color coded medicine boxes, for example, or
checklists in surgery. But it's more. They figured out what trainings and
processes provide high impacts and do them rigorously. Nurses are taught (I am
not kidding you) how to question doctors when weird things happen; identity
verification (ever notice why nurses ask your birthday like a thousand times a
day?) got extremely serious; etc.

My take: give it a few more years, and software, too, probably will follow the
same path. We needs more data, though.

~~~
sheepmullet
> Back then, too, the thoughts on medical safety also were divided into 2
> schools: the professionalism and the process oriented

The key difference is in the medical world safety has been a primary concern
from day one.

I.e. There has always been a high level of professionalism.

That is not true in the software world.

Imagine a doctor saying it's 5pm on a Friday and I'm meeting a friend in an
hour so I'll just do a rush job of this surgery and it will probably work out
fine.

I've seen devs happily check in shoddy work just to be finished hundreds of
times in my career.

~~~
sgift
> Imagine a doctor saying it's 5pm on a Friday and I'm meeting a friend in an
> hour so I'll just do a rush job of this surgery and it will probably work
> out fine.

Imaging right now. No problem. Humans are humans. Humans sometimes do rush
jobs. Or are overworked. Or stressed. Maybe they have private problems, so
their mind isn't 100% on the task.

Your suggestion that doctors are all professionals and wouldn't do such things
is actually the exact opposite of the medicine professions conclusions: Humans
make errors. Doctors, software developers, we all. And what helps to fix these
things are better tools and allowing other people to check something (see
above, nurses training to question doctors is exactly for this problems).

~~~
sheepmullet
> Imaging right now. No problem. Humans are humans

> Your suggestion that doctors are all professionals

I'm saying the level of professionalism displayed by doctors is way above the
average level of professionalism in software development.

I've worked in QA and have had dozens of developers blatantly lie to me.

How many doctors routinely lie and deliberately mislead their coworkers or
their patients? 20%? 30%?

I've been a hiring manager and have interviewed hundreds of software
developers and a huge proportion have misrepresented their actual skill set.

How many surgeons will claim they are experts in X surgery when in truth they
sat in on an X surgery once while in med school?

What proportion of doctors knowingly push suboptimal solutions because it
looks good on their resume or because they personally find it interesting?

------
planetjones
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
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
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
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.

~~~
fogetti
Such big words. In other words: non-sense.

I worked in 6 different companies in 4 different countries across 3 different
continents during my 10 years in IT. And no-one gives a shit about delivering
bug-free code or good practices.

There is such a thing called peer-pressure, probably you have never heard
about it, it works like this: while you are fiddling with your scientific
method to test everything properly, the guy sitting right next to you will get
the same feature done when by going home and putting in a lot of overtime to
make it look like he was working extremely fast and he pulled it off in matter
of days and much faster than you.

He will also give a shiny presentation and show off his working demo
application while you are still writing tests in your scientific method.

So after a few days your manager comes over to your desk and asks the guy
sitting next to you if he could do the same thing, but now in a much more
important project, where the deadline is super important. "Of course" \- he
replies, and he gets into a very interesting project and gets appraisals both
verbally and also on his linked-in profile. He also gets a salary raise, since
he is such a reliable guy who outperforms everyone. While you are still
writing tests and wondering why nobody cares about your scientific method.

I hope it's clearer now.

~~~
EdSharkey
6 companies, 4 countries over 10 years? Are you a consultant? Otherwise,
that's a LOT of job-hopping.

So, I was a consultant for a "systems integrator" for 14 years. I did
enterprise Java, web apps, and backend legacy integration work. If you are
anything like me, then you know _of course_ no one in your organization (or
the client's organization) cares about quality! You guys are hired guns, the
"tiger team". You fake it till you make it. You move around, you're like a
bedouin trader, you're a nomad.

Your comments about the coworker putting in OT to showoff and get ahead are
just you wallowing in a bit of loathing. Never ever compare yourself with
anyone else - we're all on our own tracks with our own tragedies and triumphs.
If the guy wanted to bust his ass to make himself feel good, what do you care?
God bless that dummy.

Anyhow, I think I can help with the loathing by getting a little philosophical
with you. Two questions:

1\. Are there bits of code or projects you can recall you've written over the
last decade that you're really proud of? (Like, you can tell war stories about
working on that code and you love those stories?)

2\. Is _ANY_ of the code you wrote going to be around in 5 or 3 or even 2
years from now?

The first question is to remind you of your craft, that it's really cool to
make stuff work. The second question is to remind you that almost nothing
you've done is built to last and is ultimately not going to leave any mark.

Now, don't despair. You can always take joy from your craft: let fly your
creations to work in the world and do their little jobs and then move on to
the next thing.

Reading your words, I can see that you're not taking much joy from the work
right now. You don't have quality to hold up and you don't have good team
dynamics where other people have your back.

In consulting, code quality will never be a priority nor of interest to
anyone, especially in smaller firms. And, it'll be tough to build strong teams
because you move around so much. You should really settle down in a city and
get a regular salary job. You won't take much of a pay cut once you factor in
all the benefits.

And there are plenty of big, established companies that practice TDD and have
real Agile practices. Just search around and look at Fortune 1000 companies -
the software teams working for those companies will signal quality to you
through their blogs and open source offerings on Github.

As I said before, your #1 goal should be to sleep well at night and not work
overtime. That means not being afraid of PagerDuty, not being afraid of
deploying code at the last minute on a Friday before leaving for the weekend,
not being afraid to relentlessly refactor the code to improve it, not feeling
dirty about your code because you're not hacking anymore. When you're not
afraid, you can have a team where members have each others' backs instead of
backstabbing too. That goal of sleeping good at night is totally possible, I'm
living it right now.

You need a new mindset. You need to improve your practices and start to claim
your power as the developer. Read some code quality books, write some open
source and teach yourself how to do TDD (I prefer "London" style TDD.) Listen
to some of Uncle Bob's videos on YouTube or Safari Books online if you want to
get into the groove. He's a goofball and a codger, but he's on the right track
more than he is on the wrong track.

And, buck up dude ... I hope it's clearer now. :)

~~~
fogetti
You don't know anything about me still you set off to give advices. That's not
very wise TBH.

But if you want to be philosophical, then I will be psychological with you in
exchange. I think that the fact that you write a 3 paragraph long reply to a
guy who just simply describes everyday development practices which is common
around the world tells a lot about you. Namely that you don't take very well
when people don't agree with you. Most people who are like this just want to
render themselves superior which shows their inferiority complex.

I pointed out and gave very specific examples why your ideas don't hold any
water and how unrealistic are, and then you come back and tell me even more
unrealistic things.

Also I watched all Uncle Bob's videos, I bought the Clean Coder series and I
follow TDD. Which again proves that you don't know anything about me. And no.
It's not clearer. And for the life of me can't understand why are you doing
this (but I don't even care to be very honest).

~~~
EdSharkey
> And for the life of me can't understand why are you doing this (but I don't
> even care to be very honest).

Wow.

> Also I watched all Uncle Bob's videos, I bought the Clean Coder series and I
> follow TDD.

And everyone else on the team does TDD as well? Do you work alone? I want
details about what's going wrong.

------
SideburnsOfDoom
I am in favour of high standards in software, but Mr Martin always seems to
come up short of specific measures to get there. He does not much beyond the
"man up and show some personal responsibility" school of discipline.

This doesn't seem to me to be the right way to get there. I would prefer
approaches that are driven by data, experiment and outcomes - i.e. what works.
I would expect that ideas such as "blameless postmortems" after failures,
which are inevitable; and encouraging openness and team safety would have a
better outcome than this clenched "just don't fuck up" stuff.

[https://www.inc.com/leigh-buchanan/most-productive-teams-
at-...](https://www.inc.com/leigh-buchanan/most-productive-teams-at-
google.html)

[https://codeascraft.com/2012/05/22/blameless-
postmortems/](https://codeascraft.com/2012/05/22/blameless-postmortems/)

------
tptacek
Once again, because I never really get a clear answer for this question: why
do we care? How is this not just another instance of "random dude wrong about
something"? There are tens of millions of those.

~~~
blub
This person wrote a series of books about clean code which are sometimes
recommended to junior programmers. Some people have a high opinion of him.

It's a good thing that his claims and experience are being questioned.

~~~
carlmr
I read his books and they're pretty good in showing Junior developers better
ways to structure their code.

This doesn't mean that Uncle Bob is right on every topic. Safety critical
software is completely out of his realm (at least I don't know of any project
he worked on that's SC).

From my own experience I've seen quite a few safety critical codebases and
they're often abhorrent in lack of common sense software structure, precisely
because there are so many regulations that you can't "quickly refactor"
something, and in embedded systems there are too many mechanical engineers
writing software, without caring about the craft.

~~~
blub
They're not, he doesn't back up his recommendations with data, and instead
expects readers to believe that they are appropriate and correct.

~~~
carlmr
Neither do any other coding guidelines I've seen. What data do you want to
gather about whether a name could replace a comment? It's like structuring an
essay has a lot of rules, that you can break if you know what you're doing,
but if you're just starting to write will help you be more clear in conveying
your message.

It's all subjective.

------
tempodox
Anybody who calls himself Uncle <whatever> (outside of family context) can't
expect to be taken seriously in my book. Maybe it's just me, but that seems
like an appeal to authority right there in the name.

------
jwdunne
My problem with Martin's article is that his solution isn't a catch all. In
fact, testing is aided by the examples he gives.

The things he moans about actually reduce the runtime state set of a piece of
code by moving it to compile time. It reduces the amount you need to test.

With testing, you write code that ensures a certain set of states and,
importantly, ensures against the complement of that set.

If your compiler can reduce the set of potential states, that means a few
things:

1\. Less testing code required. This is better because testing code is still
code.

2\. Catching more errors since it's easier to cover a reduced set of states.

3\. You can focus your discipline on higher level problems. Discipline is
great. It's even better when not focused on crap a compiler can pick up.

Tools are not the 'answer'. Tools are tools. If a tool helps solve problems,
it should be used.

------
henrik_w
Uncle Bob and Silver Bullets:

[https://www.hillelwayne.com/post/uncle-
bob/](https://www.hillelwayne.com/post/uncle-bob/)

makes some of the same points. Discussed here:

[https://news.ycombinator.com/item?id=15415278](https://news.ycombinator.com/item?id=15415278)

------
latch
Both better tools and better software discipline is needed.

Better tools could help a lot. It's hard to see how anyone disagrees with
that. But, on the flip side, at my most pessimistic, I find that a massive %
(say, 50%) of developers struggle to do the most basic things correctly. I
can't fathom the types or scope of tools needed to solve the size of the
problem (real AI that puts us all out of a job??).

So, while we wait for a thousand silver bullets, I agree with Uncle Bob: more
automated tests, more pair programming, more code reviews. Whatever new tool
they come up with, without basic competence, discipline and vigilance, things
aren't going to change.

~~~
le-mark
This is what I don't understand about AI proponents and/or fear mongers. Human
level AI writing code? Wouldn't that just be a lot of the same human level
bugs? Then people say Super AI will evolve more in a day than we have in a
million years. Sure, maybe, it's not known if that's even possible, at this
point.

~~~
latch
I only mentioned AI to highlight (exaggerate even) the level new tools need to
be at in order to solve this problem. I meant it in the self-aware/skynet/HAL
sort of way, not tensorflow.

------
shadowmint
We _already_ have tools that let us do the 'right thing' if we spend enough
time and money on it.

Another relevant quote from that paper, with regard to formal verification
methods:

> Any new software technology in this field must address both the cost and
> time issues. The challenge here is daunting because a reductions of a few
> percent is not going to make much of an impact.

> Something like an order of magnitude is required.

I think that's pretty much spot on.

I think that's really the issue I see; we don't need more _arbitrary_ tools
that just add _yet more_ complexity to already complex systems.

~~~
humanrebar
> ...if we spend enough time and money on it.

This is a much deeper thought than it's getting credit for.

The tools and discipline are all there. People just don't want to spend the
money for them. Developers and their leaders don't get raises and promotions
for meeting quality metrics. Product owners don't listen to people who produce
exceptionally quality products (they listen to people who say 'yes' to
unrealistic plans a lot, regardless of quality).

Why don't people want to spend the money? Sometimes they literally _can 't_
afford it. The suits are still iterating on their business plans and haven't
factored in the true cost of developing the product they will ship (which, as
all software professionals know, is different than the product they _think_
they're making).

Sometimes people can but _don 't_ afford the work necessary to product a
quality product. Way too often I see developers give a reasonable estimate
that gets stripped down because a deadline (usually arbitrary) budget or
deadline has already been set. Likewise, I see estimates get pared down
because they _seem_ too big. I also see (probably unintentional) budget
shopping, where managers ask for estimates from a few places and then
(surprise!) think the smallest estimate is probably the accurate one.

So we can go on and on about tools versus discipline, but it all boils down to
incentives and selection bias. We need to figure out how to communicate
quality to stakeholders. Or, if that's to technically difficult, we at least
need to figure out how to impart reputation to people who can provide
subjective (but better) evaluations of quality for experts to rely on.

------
k__
I talked with a few mechanical engineers, a much older profession than
software engineering. They have higher standards and whatnot, but I'm
seriously happy that I don't work in that industry. Many I talked to even
switched to SE because it's easier money and people in SE are more relaxed.

~~~
_pmf_
> They have higher standards and whatnot

Note that "higher standards" in civil engineering usually boils down to a)
having standards at all instead of fuzzy process management frameworks b)
these standards often boil down to "do this task/product with this regulatory
mandated large margin of error" and c) building according to specification
(i.e. having a reliable specification in the first place), which is exactly
how reliable software is built (SIL, ASIL, aerospace level redundancy). There
is nothing magical about it, but it needs to be driven by business and is not
something that us lowly developers can just chose to do on a whim (because it
increases costs by a factor 10 - 100).

Embracing agile (as his ThoughtWorks contract requires him to do) while
lamenting quality and lack of professionalism, as Mr Martin does, is extremely
dishonest.

~~~
sgift
> Embracing agile (as his ThoughtWorks contract requires him to do) while
> lamenting quality and lack of professionalism, as Mr Martin does, is
> extremely dishonest.

Why exactly? I fail to see the connection between lack of quality and
embracing agile.

~~~
throwawayReply
Civil engineers don't I suppose agree to build a bridge before they've
surveyed the land and then begin construction before knowing the loads.

Contrast that to software engineering, where beginning before you have
requirements is seen as a requirement of being agile.

~~~
soru
This is kind of precisely backwards. A survey is like a test; it asks 'will
this work'?

A good civil engineer will do that as early as possible, rather than produce
pages of engineering drawings blindly. A good civil engineer will calculate
the stresses and load factors on a bridge as soon as possible, rather than
assume things will work. A good architect will hand a sketch of a building to
a client as early as possible, and ask 'do you like it'?

All of those are tests, and the engineering processes in those domains are put
in place to ensure that that testing happens as early as possible, before
mistakes are too costly to undo.

~~~
throwawayReply
A test is only a test if it can fail.

All the projects I've seen, even the ones where there are "minimum viable
projects" have too much pressure from above (or have already been sold) so
they aren't _allowed_ to fail.

So I agree testing should happen as early as possible, but too often they're
not real tests because failure isn't allowed.

------
Silhouette
The points made in the article linked here are interesting, but I now
recommend anyone interested in improving the software industry simply steer
clear of Bob Martin. Sometimes he says interesting or relevant things, but
most of the time he just seems to be a professional troll these days. As far
as I can tell he has a high profile but little relevant experience or
qualification to make all these grand pronouncements or to justify insulting
those of us who think other tools or techniques or processes might be better,
so I suggest that for anyone interested in the field of high reliability
software, time would be better spent studying books and papers written by
people who have real experience and demonstrable results to support their
arguments.

------
jefe_
It is very important to have QA people the engineers respect. What makes a QA
person respectable? Strong understanding of the business logic. Clear
communication skills. Strong awareness that they cannot build the system, but
a strong understanding of how systems operate. They work as hard testing as
engineers work building, and deliver their findings efficiently. They can
accurately evaluate the magnitude of an issue. The analogy I think of is like
an offensive line to a quarterback. The engineers get the headlines, but
without a solid QA team that doesn't happen. If QA is doing a good job, make
sure everybody knows it.

~~~
EdSharkey
Or, fire your QA team, who are insanely expensive manual test script running
human robots.

Professional software developers have control of their code and don't shift
the blame for their quality issues onto other teams.

------
notacoward
Part of being a professional is listening to the experts and, even more
importantly, paying attention to the data. This applies to criticism of the
software industry as much as to the industry itself. I think what rubbed a lot
of people the wrong way about Uncle Bob's piece is that even as it called for
greater professionalism none was evident in the article's own construction,
and that seems rather hypocritical.

------
agentultra
My hunch is that tools like TLA+ and Lean[0] are bringing down the total cost
of developing more reliable software.

And developing software that is reliable shouldn't be relegated to the safety-
critical applications. There are ways that software failures can still cause
significant harm even without putting human lives at risk: security errors
allowing bad actors to steal personally identifying information, funds, or
otherwise disrupt services that could harm people. This costs people their
livelihoods, affects insurance rates for everyone, etc, etc.

I think the software industry needs to be more accountable for the influence
we're having over the lives of the public and in order to write more secure,
safer systems we need better tools to check our specifications, constrain our
implementations, and help us manage complexity.

[0] [https://leanprover.github.io/](https://leanprover.github.io/)

------
tempodox
I largely agree with the article, with one caveat:

> ...we "just" have to specify the states and behaviors that are not safe and
> prevent the software from getting into those states.

In general, the number of ways how things can go south tends to infinity,
while the desired outcomes are easier to enumerate. I think it would be safer
and more feasible in most cases to identify states and behaviours that are
valid than the other way round.

------
cryptos
Reading the paragraph about "illegal states" that should be avoided in
software, I thought of "design by contract", what never really took off.
Microsoft .NET has a really nice implementation called "code contracts", but
it doesn't seem to be used that often. However it would be a simple and
powerful way to improve the software quality.

------
DanielBMarkham
Background. When I first heard of Uncle Bob, I watched a couple of conference
videos.

Man, the guy pissed me off. He seemed quite strident in this "software
craftmanship" schtick.

As it turns out, I had written an article on all the horrible ways companies
implement Agile. It's gotten to the point that I cringe whenever I hear the
word "Agile", and I consider myself an Agile Technical Coach. Orgs just really
suck at trying to do better. Most of the time it ends up in a micromanagement
death march.

Bob read this. It pissed him off.

So Bob and I met online by pissing one another off. We commented on each
other's works, and over the years, we've become friends. So I speak both as a
coder, a consumer, friend, and a fellow talking head.

Bob means well, but with a large audience people tend to read into his work
things that aren't there. This is the HN effect: with a large enough audience
nothing you say or write will be immune from misunderstanding. He also tends
to overstate his case from time-to-time, like we all do. Hyperbole is a useful
rhetorical tool.

I restate his thesis in my own words as such: _The number one problem in
software today is hidden complexity, mutability, and state. When programmers
enter a new domain, they naturally tend to "help" follow-on programmers by
creating abstractions on top of whatever complexity they find. This increases,
rather than decreases the hidden-state-mutability-complexity problem._ It
gives the appearance of being useful, but in fact can do more harm than good.
Focusing on the tools instead of doing a good job gives this wonderful rosy
picture of progress when in fact you're headed in the other direction.

It's not that tools are bad. It's that our natural inclination to add in
abstractions easily leads to code where it's more important than ever to
thoroughly test exactly what the code does. If we focused on the testing part
first, the tools part wouldn't be an issue. But instead we focus on tools and
schedule pressure, and this leads to total crap. We buy the tools/framework
because we believe that schedule pressure forces us to work "at a higher
level" but instead that same pressure, combined with the cognitive diffculties
of adding yet more layers to the problems leads to a worse state of affairs
than if we had simply skipped the tools to begin with.

I'll never forget the shocking wakeup I got as a developer when I realized _I
am a market for people selling me stuff, and these people do not have the
interests of my clients in mind. They only have to sell me, not provide
value_.

And yes, you can argue that there's a requirements problem, but whenever
something goes wrong, isn't there always a requirements problem? Nobody ever
asks for a system that's broken, so whenever a system is broken, you can say
"But you never told me not to do X" and be correct. The fact that requirements
are a problem is tautological.

 _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._

Bob's right. When you see results like this, stay away from as many tools as
you can at all costs. You don't give hand grenades to infants, and programmers
who aren't testing don't need faster ways to complexify the system in non-
intuitive ways. The mistake this author makes is not realizing the reasons
unit testing and TDD keep getting more important year-by-year. The mistake Bob
makes is not diving down deep enough for some readers. "Craftsmanship" is a
fine label, but there's a reason we need this stuff aside from just wanting to
be professionals. If more folks understood the practical and pragmatic reasons
for the zeal, there'd be less confusion.

~~~
Caveman_Coder
What responsibilities does an "Agile Technical Coach" have and what did you do
for the business? (I'm curious because in most of the industries I've worked
in, the teams have been extremely skeptical of Agile coaches/consultants)

~~~
DanielBMarkham
_in most of the industries I 've worked in, the teams have been extremely
skeptical of Agile coaches/consultants_

For good reason. I don't blame them.

The way I see it, there are very few of us around, although tons of people
advertise using this term.

I'm the last of the general contractors when it comes to IT consulting. From
where I sit, it looks like a vanishing breed. I'm a full-stack technical lead
who has had tons of experience in different industries and technologies and
ended up, somehow-or-another, training organizations in how to use teams.
That's where the Agile comes in.

The work is this huge mix of technical and organization levels. A recent
contract had two weeks of executive/director-level work setting up a roadmap
for change, followed by a "dog and pony" show with the usual slides and games,
followed by a deep-dive with a team of leads where we set up the entire
production and CI/CD/DevOps pipeline/stack and learned TDD/ATTD and the rest
of it while writing code for an upcoming project. (This was hands-on technical
work along the lines of "how to automate cloud deployment using AWS/Ansible",
"Ping-pong pair programming in Java/Javascript/Angular", and "Architecting a
build pipeline for a team, program, and org")

I prefer the technical stuff, since so many coaches can't actually do the work
(and I used to be a show-off). The fact that most coaches in many cases can't
do the work sucks big time for the client. But it's not just technical. All of
it is important. Unless you get the execs straightened out they'll screw up
your org change without even meaning to. Unless somebody is running
interference/coordinating with middle management nothing ever happens. And the
place to start with the devs is with the leads/architects. Get them actually
coding something. Oddly enough, there are a helluva lot of leads and
architects out there that can't code. They need to get up to speed and to
understand what success looks like. If you miss any of those levels, it's not
going to work. So wether I want to or not, I end up working at all org levels,
and the best title I've got for that is "Agile Technical Coach"

I've been bugging Bob about doing some Clean Coder material on backlogs, since
they seem to be the thing that crosses all org levels and they're constantly a
mess. Bob keeps hammering on doing things right when I think it's much more
important to focus on doing the right things before you worry about what kind
of craftsman you are. I've even pitched him on a couple of ideas. Who knows?
You might see something there from me in the future.

~~~
Caveman_Coder
Thanks for the response. Sounds like your work is kind of an
development/efficiency/automation/process-improvement SME that works with all
levels of employee, from the devs to the CTO, which requires understanding of
both IT systems/dev and business.

I've seen co-workers with a similar set of responsibilities but they called
themselves "Corporate Efficiency Analysts," with the better ones coming from
tech backgrounds (sometimes having acquired an MBA after years of
development), and the poorer ones only having "general business" experience.

~~~
DanielBMarkham
Yep. There are way too many Power Point Rangers and Six Sigma Astronauts in
that bunch, however. It's tough finding a good label.

The key here is that software is everything. It's not just an add-on to some
orthogonal business model. Any more, software _is_ the business. The tech
skills are just as important as the rest of it. Most companies today are like
a group of medieval princes whose job is to correspond with other princes --
but none of them can read or write. They kind of know what they want, but for
whatever reason, they feel that it's beneath their dignity to actually make it
happen. The way we treat development? It's as if we were to start hiring
people to write our emails for us. And then complain at how correspondence is
always so difficult.

Sorry for the rant. Thanks for the chat!

------
hellofunk
Lots of talk here about better tools and better coding practices and better
discipline, but what about better languages? Some languages make it impossible
to make the kind of errors that other languages allow. And I think the
languages will just keep getting safer and safer.

~~~
sgift
I'd sum language up under tools for the purpose of this discussion.

------
nadam
Incentivization and transparency combined is also a good method, which should
be applied when possible in addition to other methods. So in case it is
possible, safety-critical code should be open source, and there should be very
high rewards for detecting serious issues.

------
tenpoundhammer
"I know there are tons of programmers churning out low-quality code."

People repeat this kind of sentiment all the time but is there anything to
back it up? I know we've all run into to random bits of code we considered
"low quality". But that can often be attributed to code that was written a
very long time ago when programming practices were much different. At the time
it was written it was likely high-quality code. It's like saying that a
Gallbladder removal surgery from 20 years ago was "low quality" because it
wasn't done orthoscopically, that technology was barely used at the time.

I'm starting to think that "tons of low-quality coders" is an industry myth to
explain a variety of unrelated phenomena. The modern-day equivalent of the
boogeyman. But let me know if I'm wrong.

------
jacques_chester
It is my continued theory that Bob Martin is a double agent, whose mission is
to discredit TDD in the wider software community by using an infuriating,
backlash-inducing writing style.

~~~
gaius
Bob Martin famously tried to write a Sudoku solver using TDD, he gave up after
a few blog posts...

~~~
pryelluw
Do you have a link to that? This is too funny to pass up.

~~~
rpeden
Just to clarify, it was Ron Jeffries who tried the TDD Sudoku solver, not Bob
Martin.

You can find links to all the the blog posts, plus some commentary here:

[http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-
so...](http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html)

I try not to be too hard on Jeffries in this case. Although he failed to write
a Sudoku solver, expressing the requirements in the form of tests can be a
decent way to start in cases where you know some valid outputs for a series of
given inputs.

I tend to solve Leetcode/Hacker Rank problems this way, and it works pretty
well. The catch is that the tests won't tell you what algorithm will best
solve the problem. And there's of course no guarantee the tests you've thought
up will cover all edge cases.

------
crdoconnor
>Safety-critical software systems, which are the topic of the Atlantic
article, are held to shockingly high quality standards.

Doesn't appear to be the case here:
[http://www.safetyresearch.net/blog/articles/toyota-
unintende...](http://www.safetyresearch.net/blog/articles/toyota-unintended-
acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code)

~~~
Caveman_Coder
I'm sure you can find specific cases where it isn't the case for critical
systems, but for the most part, I've found it to be true (having worked in the
nuclear power, power electronics, electric grid, and ICS/SCADA industries).
Sure there are cases where software fails, but in my personal, and anecdotal,
experiences, software serving critical infrastructure is held to a much higher
standard.

------
tpush
Curiously, in the list of possible future tools for more reliability type
systems are absent.

Looking at the authors bio: "I love solving tough problems with Python and
PHP".

Type systems to me seem to be (I'm not exaggerating) the answer to all
software reliability problems (barring social ones). If you want a property to
uphold, formulate it as a type. The compiler verifies.

If formulating the type is to laborious, make a weaker version and do tests it
instead.

Personally, I don't understand people arguing against type systems on
principle. Sure, they are type systems that suck (e.g. Java) or are otherwise
very verbose and thus straining. But that doesn't have to be the case, it's
not an intrinsic property of type systems.

There has to be something I'm missing since there are so many people arguing
against types, notably Bob Martin himself.

~~~
erokar
> Type systems to me seem to be (I'm not exaggerating) the answer to all
> software reliability problems (barring social ones).

That's the thing though, the "social problems" are the important problems.

I think it's a given you should use strong type systems in safety critical
software — Haskell, for instance. But look at the quote from Dr Nancy Leveson:

I've been doing this for thirty-six years. I've read hundreds of accident
reports and many of them have software in them. And every someone (sic) that
software was related, it was a requirements problem. It was not a coding
problem. So that's the first really important thing. Everybody's working on
coding and testing and they're not working on the requirements, which is the
problem.

Lack of strong typing does not seem to be the issue. Lacking domain
understanding/logical errors is the problem.

~~~
blub
I'm curious how OP would prevent the Therac incident through type systems...

Key quote: "Previous models had hardware interlocks in place to prevent this,
but Therac-25 had removed them, depending instead on software interlocks for
safety."

Or even better how type systems could work around data integrity errors in RAM
without ECC.

~~~
SomeStupidPoint
> Or even better how type systems could work around data integrity errors in
> RAM without ECC.

You realize that you can do ECC in software too, right? You just need the
statistical bound on a double fault to be similar to that of the hardware
case.

Type systems can be used to do this by defining an interface for the data,
letting you swap between normal datatypes and ECC ones seamlessly. (And in
practice, you only need to define the base operators for your new type.) You
can do this with ducktyping ECC versions of objects in say... Python. But the
type system helps ensure that you've built the full set of components
necessary and it properly links. You have to do this with ad hoc IDE tools in
Python.

Similarly....

> The defect was as follows: a one-byte counter in a testing routine
> frequently overflowed; if an operator provided manual input to the machine
> at the precise moment that this counter overflowed, the interlock would
> fail.

That actually sounds like exactly the situation that a type system would be
used to prevent -- partly because from a type theoretic perspective, that
whole situation sounds like an obvious defect.

Further, the result was because of an obscure combination of key strokes that
went untested. The use of total functions (enforced by the type system) lets
you verify (by computer) that no combination of input can transition to a bad
state.

So... Did you intentionally pick two cases where type systems are the obvious
solution to the problem?

~~~
ec109685
What stops your program data from being modified or tampwered with without ECC
ram, bypassing your checks?

~~~
SomeStupidPoint
I'm not sure I understand your question, but the one that most pertains to ECC
would be preventing corruption of the routine performing the checks --

It varies greatly by the method you use to ECC in software, since they all
feature different mechanisms.

In the case of the one I had in mind, the kernel is relatively small (so
errors are unlikely), and once loaded, it's stable against bit errors. There
are probably better answers, I'm not an expert on software ECC.

(Tampering is a different issue -- if they can tamper with the program, ECC
won't save you from them writing garbage to memory. So that a hack which can
write memory can bypass memory safety isn't really interesting.)

~~~
ec109685
I meant tampering via a side channel attack (e.g. forcing a bit flip that ecc
would protect). It doesn’t matter if your data types have referential
integrity if a hacker could disable that protection.

What I am arguing against is saying a typesafe language obviates the need for
ecc memory.

~~~
SomeStupidPoint
> What I am arguing against is saying a typesafe language obviates the need
> for ecc memory.

Which isn't what anyone said: I claimed you can do ECC in software and that
type systems assist with that by making a clean interface and verifying the
full implementation. (Since ECC is really just a lift of normal functions.)

There's little difference between using 9 bits in hardware and 9 bits in
software, except that you need to cleanly load your ECC code onto CPU cache
and you're using CPU instructions per byte loaded. The reason we do ECC in
hardware is efficiency on an operation we're doing on literally every byte.

Lots of systems, eg harddrives, use ECC in their actual formats too, because
you can do more complex ECC at the software level and not merely the extra
bit. Sometimes, this software ECC is more efficient than hardware based ECC
would be, because we're okay with less than 12.5% redundancy as long as we can
still correct the errors we expect to find.

------
gaius
Uncle Bob's product is Uncle Bob. If any software gets written, that's
entirely coincidental.

~~~
numbsafari
Thank you. He is all about creating a cult of personality. The opening of
Clean Code, with its pictures of other respected people and quotes and then
the “what about Me” is all about putting him on the same level as all those
folks. So, appeal to authority, and then run with “be a human linter”.

Also: can we stop calling him “Uncle Bob”, because it’s frankly kinda creepy
and paternalistic.

