Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: The Clean Coder

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Books 196

CoryFoy writes "As someone who has been closely involved in both the 'agile software' movement as well as the 'Software Craftsmanship' movement, I have been following the work of Robert Martin for some time. So I was quite interested when I got my copy of his latest book Clean Coder where he 'introduces the disciplines, techniques, tools and practices of true software craftsmanship.' Would his book live up to being a guide for the next generation of developers, or would it go on my shelf as another interesting book that I had read, once?" Read below for the rest of Cory's review.Before even getting into the book, it is good to know the style of Robert Martin, affectionately known as "Uncle Bob" to many people. Bob is a former preacher who comes at life — and topics he teaches — with a no-holds-bar approach. So when he approaches topics such as "Professionalism" and the software industry, I come expecting passionate discussion and serious assertions. The Clean Coder is no exception.

The book starts off with an overview of the Challenger space shuttle disaster. As a native Floridian who could see shuttle launches from my house (and, in fact, saw the Challenger explode just as it crested the trees from where we lived) this really resonated with me. 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.

We then dive right in, starting with the topic of Professionalism. The assertion is made that the key to professionalism is responsibility — "You can't take pride and honor is something you can't be held accountable for". But how do we take and achieve responsibility? Chapter one lays out two ways. To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm". The book maps this to software by saying to do no harm to function or structure, ensure that QA doesn't find anything, know that your software works, and have automated QA. In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing that QA doesn't find anything is a great concept to bring out.

Then we move on to Work Ethic — specifically around knowing your field. This means continuous learning, practice (through things like Katas and Dojos), collaboration, mentoring, identifying with your employer/customer, and practicing humility. To help with that, Chapters 2 and 3 talk specifically about saying "No" and "Yes". When we say no, and when we want to say no, we should mean it. 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. Say no and stick to it. But, when you say Yes, mean it. People are counting on you to be truthful with them.

Chapters 4, 5, and 6 begin to talk about the specific practices of coding. Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of "the zone" when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.

Chapters 5 and 6 cover Test-Driven Development and Practicing. The long and short is that TDD is becoming a wide-spread adopted practice, in that you don't get as many funny looks from people when you mention TDD as you once did. And that coding at work doesn't equal practicing your tools and techniques — instead you should set aside specific time to become better through coding exercises, reading and researching other areas (languages, tools, approaches), and attending events and conferences.

Chapters 7 and 8 cover testing practices. In Chapter 7 the book looks at Acceptance Tests and the cycle of writing them — specifically at what point the customer is involved (hint: continuously) and how to ensure they stay involved. Chapter 8 goes to more of the unit testing level, and defines some strategies and models for looking at unit testing, including an interesting "Test Automation Pyramid"

Now that we've covered the developer herself, coding and testing, the book moves on to discussing time. Chapter 9 covers Time Management strategies — staying out of "bogs" and "blind alleys", using techniques like the "Pomodoro" technique to create focus, and the law of two-feet — if you are in a meeting and aren't getting value out of it, you should feel free to (respectively) leave, or otherwise modify the meeting to get value from it.

Chapter 10 covers several different methods of estimation. In the teams I work with, estimation is perhaps one of the hardest things — not because estimating can be hard (which it can be) but because either they are held so tightly to the estimates that they are afraid to make them, or, worse, they are told what the estimates are going to be. The book really only skims the surface here, covering several techniques from Planning Poker, to PERT, to "Flying Fingers", but gives a decent overview of how to do those techniques.

Rounding out the discussions of time comes Chapter 11 and talking about Pressure. The key of this chapter is that because you have committed to your principles, practices and disciplines, you should be able to stay calm under pressure. I can certainly say from experience that the worst experiences in my career are when people weren't able to stay calm, and the way the book is laid out, if you are following the practices outlines so far, you should be able to be the voice of reason and calmness.

The last three chapters cover teams and collaboration. Chapter 12 talks about important practices such as shared code ownership, pairing, and respect for other team members. Chapter 13 covers teams and the importance of having teams that gel together. The book finishes with Chapter 14 and discussions of the importance of apprenticeship, mentorship and craftsmanship.

As I mentioned earlier, I've been involved in the "agile" movement for quite some time, and have spoken with Bob on many occasions, so many of the practices in the book weren't new. I did quite appreciate the stories he had to tell about his experiences. However, I think that some people may be turned off by the hard line around "professionalism". Sometimes you do need to say no, and I think it is good to have encouragement from a book to do that. But sometimes things are more complex, and I think that you would have a harder time looking to this particular book for help with the edge cases.

In conclusion, I think this is a book which provides worthwhile information and an interesting look at how people are looking at software development as a profession. If you read between some of the hard lines made, there are some great nuggets to be gleaned from the book for software developers of any level.

You can purchase The Clean Coder: A Code of Conduct for Professional Programmers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

Clean Coders (3, Funny)

Sonny Yatsen (603655) | more than 3 years ago | (#36427324)

Back when I was getting my CS degree, I've always noticed that the cleanest coders are also the guys who didn't shower for days at a time and always wore the same clothes.

Re:Clean Coders (4, Interesting)

chemicaldave (1776600) | more than 3 years ago | (#36427450)

I can think of many colleagues in contrast to your example. I have found the opposite. In general, people who cannot keep themselves clean and their lives organized will produce sloppy code (that includes working code with unhelpful comments and obfuscated code).

Re:Clean Coders (2)

Kenja (541830) | more than 3 years ago | (#36427668)

I dont know... I'm not the most organized person and I often forget to do dishes. But I write clean code and copious documentation because I work on a lot of projects on a lot of platforms in a lot of languages and frankly I would have a hard time coming back to an old project for updates if I didn't because I often have no recollection as to what I wrote at three in the morning in Flex for Salesforce five months ago when I've been writing Java servlets for Lotus Domino for the past two weeks.

Re:Clean Coders (1, Funny)

StikyPad (445176) | more than 3 years ago | (#36428574)

If that run-on explanation was an example of your "copious documentation," then I believe you just proved the GPs point.

Re:Clean Coders (0)

Anonymous Coward | more than 3 years ago | (#36428758)

I often tell people I am too stupid to write bad code.

Re:Clean Coders (0, Informative)

Anonymous Coward | more than 3 years ago | (#36427680)

Just because you're too stupid to understand the code it does not mean the code is obfuscated.

Re:Clean Coders (2)

Kjella (173770) | more than 3 years ago | (#36427814)

Luckily I've not run into many like that, but I think they divide into two groups. The naturally sloppy - which will write sloppy code too, and those that have just given up on real world human social life. I mean, the computer doesn't mind if you wear food-stained, ragged clothes and stink to high heaven. Your WoW-buddies will never see it. Cats and dogs don't seem to care and if they pee inside that'll really top off your smell. The last ones aren't sloppy, they "optimized" it away in the sense that why shower, I'll only get sweaty again. In fact the musk means any coworker will be glad to leave, meaning you get more time with your computer. And you don't get invited to meetings, everyone will just send documents for review. I wouldn't recommend it as a life style but some are really that odd and churn out great code.

Re:Clean Coders (1)

chemicaldave (1776600) | more than 3 years ago | (#36428458)

Upon further reflection I think sloppy code can be attributed to laziness. Laziness manifests itself in differently with different people. Some don't have good hygiene, others haven't vacuumed in months.

Re:Clean Coders (1)

Anonymous Coward | more than 3 years ago | (#36428788)

Dunno, some of worst coders I've ever met have been hell of a lot cleaner persons than I am. On the other hand, so are some of the best ones.

Re:Clean Coders (0)

Anonymous Coward | more than 3 years ago | (#36428324)

Well, you gotta have priorities.

A real coder knows that his chances of having his code looked at are infinitely bigger than having anyone look at his body.

Showering? When I could write the next piece of the most awesome piece of code ever in that time?
And clothes? Well, they are just the camouflage for the outside safari. Who needs clothes for coding?

And by the way: (Pool-)water-resistant keyboard: Best invention ever, or what?

Re:Clean Coders (2)

w0mprat (1317953) | more than 3 years ago | (#36428494)

Back when I was getting my CS degree, I've always noticed that the cleanest coders are also the guys who didn't shower for days at a time and always wore the same clothes.

I'll come right out and say it, the cleanest coders were the walking bacterial colonies, the fact that human fingers were pressing the keys was a mere detail.

Finally (0)

clampolo (1159617) | more than 3 years ago | (#36427336)

We needed a book that taught programmers proper hygiene. I have often come close to collapsing when the terrifying stench of an unclean coder has hit my nostrils. I know at least a dozen people I will give this book to along with a good scrub brush.

Re:Finally (1)

rednip (186217) | more than 3 years ago | (#36428428)

We needed a book that taught programmers proper hygiene.

Look for it hidden in any book on manners, if you don't find it right away, just keep on such reading until you get it.

Agile... please stop. (-1)

Literaphile (927079) | more than 3 years ago | (#36427350)

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

Re:Agile... please stop. (0)

Anonymous Coward | more than 3 years ago | (#36427418)

That's why I'm working on "Masturbation Coding". We all know that the best coders know how to jerk-off the machine. We all know the best develop the skills to get the computer to cum up with the answers. And then there are times when you just have to go up the rear and code dirty to get the job done.

Re:Agile... please stop. (4, Funny)

robot256 (1635039) | more than 3 years ago | (#36427488)

"Agile" programming is when you stop looking surprised and outraged when the customer changes the project requirements on you every few days.

Re:Agile... please stop. (0)

Anonymous Coward | more than 3 years ago | (#36429176)

I want to have your babies.

But first, I will produce something else, such as a small stone, for your review

Re:Agile... please stop. (4, Insightful)

Kjella (173770) | more than 3 years ago | (#36427530)

The waterfall-agile axis in software development is doing to go away as soon as the left-right axis in politics does. On the extreme left (or right, I don't really want to this to have any political meaning) you have strict waterfall, a single flow down exclusive phases. Then as you move right you have more overlaps, several delivery phases and so on. Eventually you get to agile, where you re-prioritize, redesign, code and test in very short sprints. And on the right of that you have cowboy coding, where you've given up all pretense of cycles and just do it all at once. Are any of them "right"? Probably not. Some things will require more planning, some things less depending on the project. And some claim their solution is the solution to everything. And if that there's problems with it, that's because they're not doing it right or not doing it extreme enough. The most avid agile zealots remind me a little of libertarians, if the free market isn't working it's because it's not free enough. And if the agile project has problems, it's because it's not agile enough. There's no problem that can't be solved by greater ideological purity.

Fully agreed (1)

JMZero (449047) | more than 3 years ago | (#36427990)

Sorry everyone for wasted space - but that was a beautiful comparison, perfectly summing up my thoughts as I've listened to advocates of different methodologies over the years.

Re:Agile... please stop. (1)

ADRA (37398) | more than 3 years ago | (#36428006)

Woah, that's way too much pragmatism for a slashdot programming discussion. I mean I don't think there's a single piece of mud you've slung there... very disappointing...

Re:Agile... please stop. (1)

unclebobmartin (2262780) | more than 3 years ago | (#36429102)

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

Re:Agile... please stop. (0)

Anonymous Coward | more than 3 years ago | (#36429190)

(BTW at one time doctors summarily dismissed the practice of hand-washing, even when faced with the overwhelming evidence of it's efficacy.)

You have a nice citation for that, right?

Re:Agile... please stop. (1)

swordgeek (112599) | more than 3 years ago | (#36428108)

Agile programming is pretty much equivalent of as-built blueprints. Basically, you start with a half-assed drawing, and as you build, you create your blueprints to match the building. It's become the standard for almost all buildings, and it SUCKS!

Similarly, "Agile" and "Clean Code" are pretty much mutually exclusive in my experience. Someone who can get code out the door TODAY and update it TOMORROW is going to kludge together the worst pile of regurgitated crap possible.

Re:Agile... please stop. (1)

LordArgon (1683588) | more than 3 years ago | (#36428256)

"Agile" is definitely over-used, but it actually *can* mean things. In my circle, it's always referred to a collection of traits including timeboxed iteration and bottom-up planning. I'd say to fundamental goal of "Agile" development is to codify the "release early, release often" mantra into your development process as efficiently as possible.

Re:Agile... please stop. (0)

mevets (322601) | more than 3 years ago | (#36429228)

Apparently it is the magic key to unlock a treasure trove of asinine catch phrases.

Let me summarize (4, Insightful)

elrous0 (869638) | more than 3 years ago | (#36427360)

Programming--You're doing it all wrong!

Re:Let me summarize (1)

Anonymous Coward | more than 3 years ago | (#36427782)

That comment is typical (I'm sorry to say) of many I've seen & heard in relation to this topic.
Ask youself these questions.

1) Do you write clean Code? Is it maintainable? Is it readable? What is the spaghetti rating? Are your functions/classes nested to deep?
2) Can you re-write the code from just the comments? Is it self documenting?
3) Is is 'Done', complete, FIN? If you have any technical debt then it is NOT DONE.
4) What percentage of the code is covered by your test cases? anything less than 80% is IMHO unclean.
All these things combine together to give you 'Clean Code'.

So what is it?

Btw, I've been following 'Clean Code' Principals since 1983 when I read 'The Software Reliability Cookbook'.

Re:Let me summarize (0)

Anonymous Coward | more than 3 years ago | (#36428012)

What do you mean by technical debt?

Re:Let me summarize (1)

BranMan (29917) | more than 3 years ago | (#36428230)

FIXME comments, I would imagine.

Technical Debt (1)

RotateLeftByte (797477) | more than 3 years ago | (#36428906)

In my part of the world this means more than FIXME

It is all the stuff that gets put on the black hole called a 'Todo list'. You know the stuff that never gets done.
Thus you never get 'To Done'. The code isn't finished.

Re:Let me summarize (1)

elrous0 (869638) | more than 3 years ago | (#36428394)

I'd like to take credit for it, but that was on an old poster that used to hang in my old CS department when I was an undergrad (above a picture of an angry-looking old programmer glowering at the camera). Every time I hear some programmer complaining about how the younger kids today are sorry programmers, I think about it.

all wrong? Re:Let me summarize (2)

Fubari (196373) | more than 3 years ago | (#36428124)

Programming--You're doing it all wrong!

I know you're going for +5 funny...
But what I read is "Here's some things that might be useful."
The review was well written and I appreciated the reviewer's comments on what they found interesting.

Sure, tech-skills are important.
But what a lot of programmers miss is that the other topics (estimates, integrity, responsibility) are important.
Maybe if you work on solo projects your entire life, then it doesn't matter so much.
But social interactions really are big deal in software, just like they are with every other human endeavor.
(The more cynical slashdotters would s/social interactions/politics/ and they wouldn't be wrong, but that doesn't make it any less relevant.)

Suppose somebody develops software professionally (e.g. for money).
What will help their career more: adding another language to their resume?
Or learning more about the people side of things? e.g. process, psychology & practices
(Diminishing returns start to kick in after learning your 4th or 5th programming language.)

here, have some cynicism (1)

fred fleenblat (463628) | more than 3 years ago | (#36427378)

If management would reward clean code, they would get it.

Instead they reward doing many simple tasks quickly until they realize you are getting in the way of people doing real work, and then they promote you to management.

NO I'M NOT BITTER WHY DO YOU ASK?!?!

Re:here, have some cynicism (2, Interesting)

dilvish_the_damned (167205) | more than 3 years ago | (#36427740)

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.

Re:here, have some cynicism (0)

Anonymous Coward | more than 3 years ago | (#36428042)

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.

Please read Making Wrong Code Look Wrong [joelonsoftware.com] . Also, watch the classic Star Trek episode "The Menagerie" and pay careful attention to the ending. "Everything works, but they had never seen a human before." Just because something works, doesn't mean it's right.

Re:here, have some cynicism (0)

Anonymous Coward | more than 3 years ago | (#36428136)

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.

The way code looks is only a distraction from what it does when it's not written cleanly. The learning curve should be the functionality, not the way it was written. For the person who wrote the ugly code, sure, cleaning it up is a pointless exercise. For anyone looking to use, maintain, or extend that code, cleaning it up is invaluable.

here in our ghetto... (0)

Anonymous Coward | more than 3 years ago | (#36428488)

schedule could never be met (because it was conjured out of some managers' wet dream,) so short cuts were taken with the delusion that one day we would go back to do it right. however over time those short cuts caught up with us and we're spending more and more time patching patches of patches of patches of short cuts, all the while new feature development schedule still could not be met, so more short cuts are taken... no, management felt that if it "works," it's done. no further time would be allocated for it barring bug fixes, which are expected to be quick and would not negatively impact the development schedule (did I mention the schedule is based on some managers' wet dream?)

Oxymoronic! (0)

Anonymous Coward | more than 3 years ago | (#36427382)

Jumbo Shrimp, Military Intelligence...

So Meticulously Cccclllllleeeeaaaannnn: +4, True (0)

Anonymous Coward | more than 3 years ago | (#36427390)

and full of platitudes.

For truly clean coding, I suggest soap;
however,

( To quote William Jefferson Clinton: )

"I feel your pain [teddziuba.com] .

Review or Summary (0)

Anonymous Coward | more than 3 years ago | (#36427422)

I stopped reading when I noticed the 'reviewer' wasn't actually going to review the book. He was merely going to summarize it. I mean, he even broke it down per-chapter.

XcepticZP

Re:Review or Summary (3, Informative)

CoryFoy (2254778) | more than 3 years ago | (#36427464)

Fair enough comment. I do add my viewpoints on the section, and summarize it at the end. I find most books I read can't be summarized nice and tidy at the beginning, but instead need some background throughout. This book is especially true of that, because it's like a collection of short essays more than one contiguous writing.

Appropo... (1)

gregarican (694358) | more than 3 years ago | (#36427452)

Bump this [youtube.com] while yo checkin' yo braces and semicolons...

Quality (2)

Dog-Cow (21281) | more than 3 years ago | (#36427490)

In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.

Given the number of mistakes in this sentence, along with the pompous notion that process can somehow prevent logical errors, makes me very glad I don't work with, much less for, you.

(If you code for NASA, perhaps you have the luxury of a process that does prevent logic errors. Somewhere around 99.9999999999% of us do not.)

Re:Quality (2)

CoryFoy (2254778) | more than 3 years ago | (#36427660)

I think you misconstrued my point. Let's say you find a logic error during code review. That means your process is working well. Let's say another bug slips out to production. That means there is something in your process that didn't catch that. Perhaps it's more automated testing. Perhaps it's more code reviews. Perhaps it's more communication. Perhaps it's closer oversight of junior developers. The point being that when you find a bug in your QA or Production cycles, go back and look at your development process to see what let that through. Sure, you may not find them all. Sure, the cost/benefit analysis may not be worth it. But it stands that we tend to blame individuals whenever a bug hits production instead of stepping back and looking at our overall process to see what led that bug to slip through. Of course mistakes happen. It's what you do about it as a team and as an organization that matters next.

Re:Quality (2)

Fubari (196373) | more than 3 years ago | (#36428338)

... the pompous notion that process can somehow prevent logical errors

Pompous?
Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD) [agiledata.org] .
excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

So... what's your strategy for preventing logical errors?

Re:Quality (1)

mcmonkey (96054) | more than 3 years ago | (#36429282)

... the pompous notion that process can somehow prevent logical errors

Pompous?

  Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD) [agiledata.org] .

excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

So... what's your strategy for preventing logical errors?

Yes, pompous. There are no valid blanket statements on the meaning of bugs found during testing. That would depend on the bug found. Could be a systematic issue with the development process. Could just be that people aren't always perfect.

A bug found in testing could be due to an issue in development, an issue with the requirements, an issue with the test.

In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.

So if my testing finds a bug, all other work needs to stop so the problem with my process can be addressed immediately. (Even if the problem with my process is just that people are involved.)

So what if I water down my QA process so that no bugs are found, no matter how bad the code is? Does that mean there are no problems with my process?

Re:Quality (1)

skids (119237) | more than 3 years ago | (#36428402)

Besides, it it plainly clear that he is behind the times. Modern industry has solved the problem of QA "finding something" by laying off the entire QA department (and treating customers as BETA testers.)

Is it just me (0)

Anonymous Coward | more than 3 years ago | (#36427590)

Or do agile developers remind anyone else of religious zealots? Or worse: LARPers!

Re:Is it just me (1)

RotateLeftByte (797477) | more than 3 years ago | (#36427834)

I do find many agile devs are verging on the Fanatical. This is rather sad IMHO. There are some good ideas BUT taken too far they are overkill.

I prefer the mantra, "Do it right, Do it once."

Ha Ha. (1)

unclebobmartin (2262780) | more than 3 years ago | (#36427614)

I deleted the Hygiene chapter before I published the book. I figured it would be a little too remedial. Maybe I should have left it in. At least the part about the breath mints.

Re:Ha Ha. (1)

RotateLeftByte (797477) | more than 3 years ago | (#36427870)

Kudos for posting her Uncle Bob. I've seen one of your 'shows'. The only thing I can say is 'Sport On the Nail'.

You have to pay for clean. (5, Insightful)

DarthVain (724186) | more than 3 years ago | (#36427624)

The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.

I think the best analogy for this is furniture.

Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.

IKEA makes some pretty shitty furniture but is good enough for many applications. It is cheap, and fast.

What most consumers and managers want, is the quality and hand craftsmanship of the Mennonites, at the speed and cost of IKEA.

Problem is, that is impossible for the most part, particularly when you start looking at very large scale applications. So when managers hire people they want the IKEA drones, and expect them to produce Mennonite quality very quickly. Bottom line is short cuts are taken, managers "risk manage", and in the end you get buggy code that is not clean at all. Particularly when you have a work force that is treated like replaceable parts, in many cases you are dealing with someone else's mess, why should you try and code cleaner?

Anyway, none of this is new, and I am sure on small applications were individuals have more control, cleaner code is possible, however in the corporate world, given the outlook by most, I can see it being problematic.

Re:You have to pay for clean. (1)

bfwebster (90513) | more than 3 years ago | (#36427812)

"...pick two."

If you're lucky or very good. In lots of projects, you get to pick just one. ..bruce..

Re:You have to pay for clean. (1)

DarthVain (724186) | more than 3 years ago | (#36428054)

LOL too true!

Usually that one is "Cost" in my experience.

Re:You have to pay for clean. (0)

Anonymous Coward | more than 3 years ago | (#36427874)

Speed, Quality, Cost, pick two.

That's only true when looking at narrow slices of time or selected examples. On a broader scope higher quality software is easier to maintain which allows for faster average times for changes and thus a lower cost.

Yes you can red line an engine, you can even do it for a long period of time, but it will wear out faster that way and result in higher maintenance costs (if you don't break it entirely). The same applies to a development team and its relationship to their software.

Ah bad car analogies, is there anything you can't do?

Re:You have to pay for clean. (0)

Anonymous Coward | more than 3 years ago | (#36428134)

It's always true. The speed at which management expect you to develop will always end up being faster than you can reasonable develop high quality code complete with automated BDD test cases with 100% test coverage.

At that point the best coded piece of software will go to ratshit.

Re:You have to pay for clean. (1)

Saxophonist (937341) | more than 3 years ago | (#36428210)

It's always Speed and Cost where I am. I wish it was ever quality.

Re:You have to pay for clean. (1)

swordgeek (112599) | more than 3 years ago | (#36428212)

This is true. But companies (and by extension, the hiring managers) need to understand where they're making their money.
The Mennonites could (theoretically) give up and start making second-rate crap for the same price, and make a big short-term profit. Suddenly they could product five times as much and sell it for the same price! Until their cost-cutting caught up to them, and people quit buying their furniture at a premium.

A company which has programming as a *primary function* needs to spend money on serious programmers and a proper environment for them. They need to spend time and money to get what they need to establish a name for themselves. On the other hand, they can probably get away with fairly cheap desk accessories (Note: Not chairs - good chairs are essential!) and aesthetic furniture. On the other hand, an interior design magazine would not be able to get away with less than top-notch casual furniture, decorations, and the like.

Here's a good piece of advice for managers and executives: Are you trying to cut costs in your primary business? If so, you're probably in trouble.

Re:You have to pay for clean. (2)

jeffmeden (135043) | more than 3 years ago | (#36428854)

The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.

I think the best analogy for this is furniture.

Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.

Example fail. If Mennenites abided by your "pick two" rule and they were slow but produced high quality, they would be cheap. Instead they are expensive to boot, and are apparently working under the "Pick 1" rule.

Re:You have to pay for clean. (1)

Anonymous Coward | more than 3 years ago | (#36428894)

They are slow, but only because they do everything by hand. And you don't order a chair and wait around while it's being built; you just tell them which chair you want and they load it into your truck... so for your purposes, it IS fast.

Re:You have to pay for clean. (1)

ChaoticCoyote (195677) | more than 3 years ago | (#36429248)

Well said, sir.

Goto-less programming (1)

Relayman (1068986) | more than 3 years ago | (#36427638)

I saw some open source the other day riddled with gotos. I learned (in the early 70s) how to write structured code (where any statement in the code has exactly one entrance point and exactly one exit point). To this day and millions of lines of code later, I still don't use gotos (and pseudo gotos like iter). I wasn't shocked to see the cruft in the open source, but I am disappointed that the review didn't mention structured coding.

The reality is that bad code these days is much worse than the bad code of yesteryear (just read The Daily WTF [thedailywtf.com] for a plethora of examples). Maybe someday we'll go back to what we had when we were working on "proving" that programs worked instead of just testing them.

Re:Goto-less programming (1)

Bryan3000000 (1356999) | more than 3 years ago | (#36428234)

Proof that it works to within a certain margin of error given specified system parameters and on hardware proven to be within certain specifications and failure rates? I believe that software engineering still exists as a discipline. Proving software without system specifications is impossible from an engineering perspective, but there is still testing. Is that what you're griping about?

Re:Goto-less programming (1)

JonySuede (1908576) | more than 3 years ago | (#36429134)

I dont care about your rant but I care about the gotos
Gotos have there place in structured error handling in C. [thegreenplace.net]
And your dogmatism prevent you from favoring readable code over an artificial limitation (exactly one exit point) since the more readable way to express a guard condition is to do :
if(!isGuardConditionMet())
      return ERRNO_GUARD_UNMET;

I've been programming for over 20 years... (1)

GigaHurtsMyRobot (1143329) | more than 3 years ago | (#36427706)

The last thing 'coders' need is another book telling them exactly what practices they should be following. As with most things, the focus should always be on creating a working product first. After you've built something, then you can refine it and clean it up. Too often when the focus is on how it is to be completed instead of actually completing it, the latter never happens. Re-factoring is a much easier task when you already have it working, already know exactly what it should do and when, and have experience using it which helps break it down more intelligently.

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

timeOday (582209) | more than 3 years ago | (#36428196)

I agree that some degree of "hack first, refactor later" is good, AFTER you have a reasonably solid foundation to build on. The problem is if you hack first and then lose the motivation or the funding to do the refactoring. Then you are stuck living with your first draft forever, and even trying to build on top of it.

Re:I've been programming for over 20 years... (4, Interesting)

ChronoFish (948067) | more than 3 years ago | (#36428320)

I've been programming for about 17 years..... and I've found you can't clean code "later". Once it's working it's off to testing and then shipped/delivered. No manager wants you to refactor code unless there is a damn good reason to do it (i.e. there is a bug or enhancement). If you refactor at that time now your next project is actually two projects (a refactor project followed by an enhancement project).

The very idea of refactoring code killed Netscape. They rewrote their underlying rendering engine- a triumph of the developers - with no (little) noticeable enhancement for the end user. Users who were developers "got it" - but the mass market did not.

-CF

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

Lord Grey (463613) | more than 3 years ago | (#36428336)

While I utterly agree with your statements (and I've been programming for almost 35 years) 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."

Then, you wind up with the code you see around you and someone decides to write a book about how to "fix it."

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

unclebobmartin (2262780) | more than 3 years ago | (#36428834)

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

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

gutnor (872759) | more than 3 years ago | (#36428538)

It depend how you define 'working'. Nowadays working should mean clean, with automated tests, little/no dead feature, little/no overengineering, no 'entreprisification', made with the right too for the job if possible, and finally coded with care (meaning coded to be read easily by fellow developer, no by tools or manager )

If that's what you have in mind by working, that is what Robert Martin generally advocate (see the other book called Clean Code): get the stuff working in a way you don't have to worry about the future because your code is clean enough so that you can refactor easily later. Haven't read this one, but I doubt he veered too much of that path.

Now, "working", in management speak, is synonym with "sold". Which cover the above scenario, but also the hacked together prototype written in VBScript by a consultant 5 years ago, converted by an automated tool to F#.Net (for no good reason), tortured to work behind the Company Mandated SOA framework, "tested" by hand by a team of 50 indian developers kept demotivated by stupid targets.

Cleaning up the mess of a hacked together application is tremendously difficult. Budget for improvement are based relative to the cost of the project and other improvements, making it even harder to justify actual cleaning up (hacking is cheap, especially because hacking generally means no testing). When the project is in production with big client, even minor change to stuff like datamodel, internal interface, message format, ... will require from the client a full regression test - which means that there is resistance to change all the way. Then you have backward compatibility with your own broken interface and integration with the rest of the product portfolio which can have vastly different release plan, and then you have to deal with the design problems in other application that "bleeds" into you own (like - hey let use the portfolio position table in the database that store the position in a *double*)

In last 10+ plus developing applications,with one exception, "working" has always meant either hacked together without testing or so legacy that no refactoring is small enough to be possible. A lot of the problem would not have existed to such extend with coder caring about their code. That require skills, and books.

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

unclebobmartin (2262780) | more than 3 years ago | (#36428760)

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.

This is true (1)

Giant Electronic Bra (1229876) | more than 3 years ago | (#36429030)

But that is EXACTLY why 'agile' development methods place a high degree of emphasis on working code. Iteration 1 should WORK, every iteration from 1 to N should work. The early iterations of larger projects may not do anything exceptionally useful, but they have to run and pass acceptance tests. Thus you're always squarely centered on extending a working application and 'cleaning it up' (continuous integration). You never spend time working on anything that isn't part of some actual working functional part of the application being developed. Now and then that actually means you may code something in a way that is clearly not the final end result, but that's OK because you will always be in a position where you have an actual working application. If the customer decides later they don't want X, then you just never do X and if X would have required refactoring Y then good, you already have a Y that does everything else sans X.

It really does work, and the emphasis really is NOT on process, but on practical problem solving. Process is "what actually did work best in practice".

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

TemporalBeing (803363) | more than 3 years ago | (#36429036)

The last thing 'coders' need is another book telling them exactly what practices they should be following. As with most things, the focus should always be on creating a working product first. After you've built something, then you can refine it and clean it up. Too often when the focus is on how it is to be completed instead of actually completing it, the latter never happens. Re-factoring is a much easier task when you already have it working, already know exactly what it should do and when, and have experience using it which helps break it down more intelligently.

The problem, as your 20 years of programming experience should tell you, is that often management will never allow the "clean-it-up" so you get saddled with how you did it the first time, even if you only meant it to be a prototype. So, doing your best to get it as close to right the first time - through discipline and good practices to start with, will help you all the more in the long run.

While I haven't RTFB, I will have to agree that more information on this topic is very, very necessary. Often, programmers do not know how to estimate their time - it's skipped in CS/IS/IT/SE curriculum - and there's not much good stuff on the topic available, with most everyone saying "it's too hard". Good material will help the field mature in ways that are desperately needed, and old-timers saying "not another book" is not going to help that.

I need suggestions!!! (-1)

Anonymous Coward | more than 3 years ago | (#36427712)

Okay gents, apologize for being OT but I'd like some advice. Most of the time around midday the office clears out and I can relax some. The co-workers all having a spot of tea and the like. So happens today I felt the urge to break wind since my cubicle mates are all out. Lo and behold I think I overdid it and probably shat myself. As a matter of fact I feel the seat of my pants sticking to my chair.

Now my co-workers are all starting to file back into the office from being away. What should I do? I don't have a spare set of trousers to take to the restroom. But I know I must be reeking by now. How can I sneak out and past my boss, who is now starting to make his way to my desk?

HELP!!!

on boolean logic, and zealotry (1)

RockGrumbler (1795608) | more than 3 years ago | (#36427738)

"Saying, "We'll try" means that you, or your team, isn't already giving it their best"

In my experience, it means "We don't know, let us go off and research it more."

On a side note. I'm sick of the attitude that programming process and dogma is the one true way to make yourself a better programmer. Just attend one more conference or buy one more book to acquire your true path to coding nirvana from someone else.

The edge cases that aren't covered by pre-ordained process are REAL LIFE, and you are often the only person who has enough context to make good calls about process and procedure. Spending your whole life fine-tuning your work flow to imitate the sub-deities of agile seems wasteful and quite UN-JOYFUL. I wish more folks would just pick and choose the things that work for their group based of of honest experimentation, and go about their life BUILDING COOL THINGS.

Re:on boolean logic, and zealotry (1)

JonySuede (1908576) | more than 3 years ago | (#36428962)

quite UN-JOYFUL.

Right on, as the Beasty Boys once sang :

You heard my style I think you missed the point it's the joy.

joyful programming <-> productive programming

"Uncle Bob" (0)

Raenex (947668) | more than 3 years ago | (#36427802)

Robert Martin, affectionately known as "Uncle Bob" to many people.

Ugh.

Re:"Uncle Bob" (0)

Anonymous Coward | more than 3 years ago | (#36428048)

At least it's not "Uncle Remus".

Can someone explain to me... (0)

Anonymous Coward | more than 3 years ago | (#36427934)

Why does this book have the crab nebula on the front of it? I did a quick search of "Uncle Bob" and it seems several of his books feature astrophysical images. What is up with that? (not necessarily complaining, but I was kind of disappointed when I saw the Crab and it turned out to be a programming text.)

Re:Can someone explain to me... (0)

Anonymous Coward | more than 3 years ago | (#36428166)

you could have a word with Tim O'Reilly

I found this sentance odd. (1)

shadowrat (1069614) | more than 3 years ago | (#36427956)

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.

Re:I found this sentance odd. (1)

unclebobmartin (2262780) | more than 3 years ago | (#36428914)

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.

Re:I found this sentance odd. (1)

mcmonkey (96054) | more than 3 years ago | (#36429202)

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.

Sounds like you're just the guy this book is for, saying you'll try when you should be saying no.

When I say, 'I'll try,' I mean, I'll try. It means, I don't know if the request is possible given the available resources, or I have check for conflicts with existing requirements, or I'm not sure if the request is technically possible.

"Saying, "We'll try" means that you, or your team, isn't already giving it their best". WTF is that crap? "Uncle Bob" sounds like a pompous d-bag.

Perhaps "I'll try" means I'm open to learning and growing. There may be something I cannot do today which I will be able to do tomorrow, so rather than saying no, I do some research. I don't consider that "extraordinary effort."

"a no-holds-bar approach"?? (0)

Anonymous Coward | more than 3 years ago | (#36428020)

Again, here we have programmers who can memorize that $%@^! is not the same as $%@!^ but ask them to know english??? It's "NO HOLDS BARRED". DUH.

3 companies, 3 agile failures (4, Interesting)

Anonymous Coward | more than 3 years ago | (#36428052)

I've worked at 3 different companies of all sizes in the past 8 years. Every one claimed to be Agile, every one one of them produced undocumented spaghetti code that collapsed under the slightlest change request.

"Agile" unfortunately has become an excuse for no plans, no docs and no discipline.

Therefore, having never been employed in a real Agile environment, what about Agile lends itself to be abused this way?

Re:3 companies, 3 agile failures (1)

Anonymous Coward | more than 3 years ago | (#36429032)

>> Therefore, having never been employed in a real Agile environment, what about Agile lends itself to be abused this way?

Many agile methods (scrum, extreme programming) promote some level of developer self organisation. These methods are predicated on every developer being able to exercise sufficient judgement to decide and execute on what's best for the project, the implication being that management is an overhead developers can and should live without. As a consequence top down management is caricatured, with Dilbert as an unspoken reference point.

In fact, developers are absolutely dreadful at self organisation. Conversations veer off into rabbit holes on wafer thin evidence (for example, whether communications between major systems components should be synchronous or asynchronous) with vague phrases such as "over-engineered" and "future-proofed" thrown about without the slightest consideration on the overall cost of these conversations (flame wars, often) on the project, nor on how much it would be to retrofit the alternative thereafter. Also, without a very clear reward and punishment structure on less interesting but important aspects, such as documentation (code + tests is rarely sufficient), these points are often neglected.

The reality is that just as most developers are mediocre but think they are better than average, so are most managers. Working for pragmatic, technically literate managers who know the customer's business domain at least as well as the customer is a truly liberating constraint. Sadly, many developers have not and have no benchmark for comparison or demanding more of their managers. Even so, asking mediocre developers to self organise is a recipe for delay, overspend and underachievement. To add insult to injury, the claim will be made that because a series of irrelevant unit tests turn green and because unintelligible documentation exists, the code is "clean".

Re:3 companies, 3 agile failures (0)

Anonymous Coward | more than 3 years ago | (#36429144)

Agile cannot fix a dysfunctional team who is barely capable of putting out working software. Agile takes a good team and takes the roadblocks out of their way so that they can be a great team.

Trashbin (0)

Anonymous Coward | more than 3 years ago | (#36428160)

"As someone who has been closely involved in both the 'agile-- Throw it in the trash.

Never.. (1)

ADRA (37398) | more than 3 years ago | (#36428238)

read the book, but ANY text that enforces a mandatory set of principles to program probably has a healthy amount of:
1.overly dogmatic approaches to solving a problem. The zealots will eat it up and constantly espouse the belief to all within ear shot, but unless institutionally mandated will probably be ignored for a variety of perfectly viable solutions. Eg. Web Session Persistence: Thou shalt never store state within a web session context and you will perform all backend processing with either cookie or DB looked up data. The idea is sound and it makes a lot of scaling problems go away, but there are times/places/situations where web session contexts on web servers are perfectly valid solutions to a given problem. I find books of similar ilk will tackle problems by shoving one solution down the reader's throat and completely eschew the exception or the philosophically diverging opinions.

2. too many pedantic problems/solutions in that everything stated is either terribly obvious to any programmer of a certain benchmark quality or so trivial that static analysis could identify the problem. There are definitely patterns that should be avoided like the plague, and the earlier a developer identifies them the better. Assuming your language of choice can be statically analysed, this is a non-issue, but I suppose -someone- needs to cook up these best of breed solutions to trivial problems, but I'd envision a web page that took in these types of problems as a collection as a better approach. A single book seems to be too dated and too ridged in its recommendations. Adding a rev to a programming language or library could vastly change what is recommended / disdained causing someone to publish a brand new book, etc...

There is a good reason to have documentation on why solution X or Y is the best of class for a given set of problems, but the zealottry and scope of said solutions always seems lacking. A good book will given concrete solutions and properly scope the solutions for targeted purposes. Of course a very narrowly focused book won't sell nearly as well, so they tend to not get made.

I'd say that #2 rules of thumb are best presented in a web focus so that they can breath and evolve as the communities that use them evolve. Having books on the subject just solidify rules of thumb that shouldn't be fixed in stone.

We have too many tools to write clean code (0)

Anonymous Coward | more than 3 years ago | (#36428436)

I hate hate hate web development. I long for the days of DOS 5 and Turbo C.

Example:
html/javascript. Use + to concatenate your strings. Send a AJAX msg to php where you use '.' to concat your strings. And maybe you need to chat with some Python which is living in a world all its own. And pass your messages back. JSON? xml? mystery mosh? it goes on and on. Every new language and tech has to do everything a little different from everything else. Listening to new languages justify themselves is like reading nerd masturbation. It is impossible to hire even a senior dev who knows all the tools you use, even though where he worked previously he created the exact same result with an entirely different set of tools.

It is just insane. How anyone can be expected to product good code with all the overhead of competing/complementary languages and platforms. I'm no javascript fan but if we really are moving to a one-language, one UI world. I welcome it. Then maybe we can start to see some decent code again and we won't need books like this anymore.

Re:We have too many tools to write clean code (1)

sycodon (149926) | more than 3 years ago | (#36428978)

You had no reason to post this as an A/C. It's perfectly reasonable.

We have taken an application (web browser) which was initially designed to show text (and later porn) and kludged together a generic client supporting what is essentially a client server architecture. Code runs on the server, which, in addition to access the database, writes and downloads code that runs on the client. It used to be that the client was a full featured application that supported the entire GUI toolset, was always aware of its connections and objects, and used a single language.

Now we have browsers operating in a "stateless" manner, where they essentially gets amnesia all the time, use a mish mash of different languages and bolt-ons to make up for deficiencies and are incompatible with other browsers.

The existing web application architecture is poorly thought out and badly implemented.

Hippocratic Oath (1)

StikyPad (445176) | more than 3 years ago | (#36428460)

To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm".

Hopefully the book is better researched than the summary suggests -- "First, do no harm" is not a part of the Hippocratic Oath.

http://en.wikipedia.org/wiki/Hippocratic_Oath#Modern_version [wikipedia.org]
http://en.wikipedia.org/wiki/Primum_non_nocere#Origin [wikipedia.org]

Re:Hippocratic Oath (1)

CoryFoy (2254778) | more than 3 years ago | (#36428546)

Likely my fault. Although, from your links (http://en.wikipedia.org/wiki/Primum_non_nocere):

"The Hippocratic Oath includes the promise "to abstain from doing harm" (Greek: ) but does not include the precise phrase."

So it's not all *that* far off. But thanks for the clarification!

Re:Hippocratic Oath (2)

unclebobmartin (2262780) | more than 3 years ago | (#36429008)

No, not your fault. I was blissfully unaware that the oath did not contain the phrase. Shame on me for not checking that!

Belief. Things you know? (1)

esmrg (869061) | more than 3 years ago | (#36428492)

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

Re:Belief. Things you know? (1)

PCM2 (4486) | more than 3 years ago | (#36428874)

To be fair, though, too: Nobody at NASA actually predicted an accident, and the specific accident was not the result of some miscalculation (contrary to the wording of TFA). If management steamrolled over the engineers' objections, the result was that the Shuttle was less safe than it could have been. In fact, the vehicle should have been considered unsafe. What constitutes unsafe in this case? According to Richard Feynman, it was "a chance of failure of the order of a percent (it is difficult to be more accurate)." So even ignoring engineers' objections, the chance that the mission would go off without a hitch was still considered to be around 99 percent. By NASA's professed standards, that's not safe enough -- but to say that the accident was the result of bad management, I think, goes a little too far. Could the accident have been avoided? Certainly -- there were 99 out of 100 things that could have happened that would have prevented the accident, instead of what actually did happen. And if they reduced the chance of failure to one-half of one percent, there would have been slightly more than 99 out of 100 outcomes where nothing would have failed, and so on. Could "standing up for what you believe in" have prevented the accident with 100 percent certainty? Only with the crystal clarity of hindsight.

Re:Belief. Things you know? (2)

unclebobmartin (2262780) | more than 3 years ago | (#36429274)

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

Is the book based on research? (1)

olau (314197) | more than 3 years ago | (#36428714)

Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?

Not that there is necessarily anything wrong with anecdotes and good advice, you can learn a lot from the success of others. It's just that there's a lot of advice flying around in this trade, and not all of it has as firm a base as it sounds like, ahem, Extreme Programming, ahem. The note about staying out of the zone sounds more in the anecdotal than the scientific category to me.

Another way to look at this... (1)

RogueWarrior65 (678876) | more than 3 years ago | (#36428808)

"Obfuscated coding" is another way of saying "Job Security". I can remember working for a Fortune 500 company in the early 90s where they had to pay a small fortune to get retired Cobol programs to recode for Y2K. I also remember buying someone else's code sight-unseen thinking that the guy was talented only to discover that the guy had the sloppiest code I'd ever seen.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>