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