Comment Re:Let me summarize (Score 1) 196
What do you mean by technical debt?
This is the definitive article: http://www.martinfowler.com/bliki/TechnicalDebt.html
What do you mean by technical debt?
This is the definitive article: http://www.martinfowler.com/bliki/TechnicalDebt.html
Being a manager, I am learning to hate the phrase "clean code". It seems to be a preoccupation with how code looks whilst being a distraction from what it does.
Not quite. Clean code is not about looks, it's about behavior. It's about how the code behaves when you try to change it. Code is clean if it is easy to change. Code is not clean when it resists change. If the estimates of your programmers are growing for no reason you can divine, then the reason is almost certainly that the code is getting dirtier and dirtier with every passing day.
This over-use of "agile" to describe programming needs to stop. Please. It's a mean-nothing word. "Agile" and has turned into a useless fluff phrase (has it ever been anything but?).
I just did a search. The text of the book uses the word "Agile" five times, all as side references. The book is decidedly _not_ part of the Agile canon. Rather it is a book about how to behave as a professional programmer.
Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?
As the author, I feel able to respond. This book is a book about how to behave as a professional programmer. It is not a book about how to write code. As such it is not, and could not be based on any kind of scientific research. Rather it is based on my 40+ years of experience as a programmer, and on the mistakes I have made over that time. This book contains all the things I wish I had known when I was in my thirties.
To be fair, though, too: Nobody at NASA actually predicted an accident,
The Thiokol engineers were very emphatic that the mission should be postponed. They _did_ say, in no uncertain terms, that the mission was at risk, including the loss of the orbiter and crew. This was not a prediction, but it was a clear warning by the experts responsible for the SRB.
...The accident was a result of engineers saying no, but management overriding the decision. With this introduction, Bob makes it quite clear that when we choose not to stand up for that which we believe, it can have dire consequences.
There are some things that bother me here. (And they should bug you too)
1. The engineers did indeed stand up by saying no, but authority didn't give a fuck. In the end the engineers did not have control of the project. 2. The engineers didn't merely believe, they knew. I'm sure there were test results and rigorous math involved. Yes, I understand the terms are too often used interchangeably but it's important to know the distinction. When some yahoo stands up for his belief in, I don't know, let's say, god, there is big difference. Belief does not require proof.
When you stand up for something you can't prove, that can have dire consequences as well.
Granted, this writer is a former preacher, and it shows.
I have to say that I don't quite understand your point. What does the "preacher" statement have to do with my comments about the Challenger accident? Can you be specific? What, precisely, does it show?
BTW, I _was_ a preacher three+ decades ago in my young and foolish twenties; but I got over it before turning thirty. I am now quite content to be an atheist.
You are quite right that the engineers stood up to say NO. They wrote memos and held meetings. They were very upset. In the end some of them refused to watch the launch over the issue. No, they did not "know" that there would be an accident. But they were very concerned. They did not have enough evidence to be conclusive, but the implications of the evidence that they did have was very scary. In the end, their concerns were overridden by managers who made the choice to ignore their experts.
My final point in the introduction was that if I were one of those engineers I'd be haunted by the question of whether I should have called Dan Rather.
Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off.
I say this a lot. Usually it coincides with a feeling that we have been given a task, usually using some new or otherwise unproven technology or techniques, with hazy specifications on a fixed and frankly uncomfortable timeline. Generally the first answer is no, but it becomes apparent that we don't really have a choice in the matter, our job is to do this thing. We say it just to placate ourselves and make it sound like there is no expectation of success.
"We'll try", to me, has always translated to, "We're doing this against our better judgement."
I'm sort of interested in reading this book and finding out if there's more to this situation that the review detailed.
The problem is that _you_ may interpret "We'll try" as "We're doing this against our better judgement." However, your boss will likely interpret it to mean: "We're on it! We'll succeed!" Frankly saying "We'll try." is often used as a way to end an uncomfortable conversation; leaving it in an ambiguous state. It's easier than saying: "No.", which is what really needs to be said. When you accede to the demand to "try", you are admitting that you weren't trying before.
the reality is that management usually gives coders virtually no time to clean things up. There is constant pressure to move on to the next task or project, with little thought to hardening or refactoring something that already seems to "work."
One of the lessons in the book is that a professional programmer will not allow this to happen! As professionals we need to understand what it means to be a professional, and what that implies about our relationship with our employers. A professional is hired for his/her knowledge and expertise. When you hire a professional, he tells _you_ what to do! When you hire a doctor, or a lawyer, you don't tell them what to do, they tell you what to do. "You need to have your appendix out." When your manager says "We need to go fast, so don't refactor" you reply: "The way we go fast is by refactoring. Since you want me to go fast, I must refactor."
"I am, therefore I am." -- Akira