Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:here, have some cynicism (Score 1) 196

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.

Comment Re:Agile... please stop. (Score 2) 196

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.

Comment Re:Is the book based on research? (Score 5, Informative) 196

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.

Comment Re:Belief. Things you know? (Score 1) 196

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.

Comment Re:Belief. Things you know? (Score 2) 196

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

Comment Re:Agile... please stop. (Score 1) 196

Imagine doctors who live on a continuum of the opinion that cleanliness is effective in reducing infection. Which are right? Are any? Or should we be tolerant of doctors who operate with dirty hands? (BTW at one time doctors summarily dismissed the practice of hand-washing, even when faced with the overwhelming evidence of it's efficacy.)

Comment Re:I found this sentance odd. (Score 1) 196

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.

Comment Re:I've been programming for over 20 years... (Score 1) 196

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

Comment Re:I've been programming for over 20 years... (Score 2) 196

This book has no code in it. It's not about code at all. It's about coders, and the attitude they need to survive in a corporate environment. It's about being professional. About saying what you mean, and meaning what you say. It's about how to answer a manager who want's the impossible. It's about finding a way to write effective code just after you've had a big fight with your spouse. It's about all the non-coding things that programmers face every day.

The more cordial the buyer's secretary, the greater the odds that the competition already has the order.

Working...