Slashdot Mirror
Book Review: The Clean Coder
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.
The Clean Coder: A Code of Conduct for Professional Programmers
author
Robert C. Martin
pages
256
publisher
Prentice Hall
rating
5 Nebulous Rating Units
reviewer
Cory Foy
ISBN
978-0137081073
summary
A good overview of the current agile practices for software developers
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.
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.
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.
My postings are informational and does not constitute legal advice. Act on it at your risk.
Programming--You're doing it all wrong!
SJW: Someone who has run out of real oppression, and has to fake it.
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?!?!
Bump this while yo checkin' yo braces and semicolons...
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.
"Agile" programming is when you stop looking surprised and outraged when the customer changes the project requirements on you every few days.
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.)
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.
Live today, because you never know what tomorrow brings
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.
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.
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 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.
If I used a sig over again, would anyone notice?
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.
"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.
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."
I'd rather be riding my '63 Triumph T120.
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.
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.
Let's not stir that bag of worms...
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...
Bye!
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?
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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.)
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.
Bye!
"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.
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.
The force that blew the Big Bang continues to accelerate.
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
http://en.wikipedia.org/wiki/Primum_non_nocere#Origin
https://www.eff.org/https-everywhere
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.
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.
"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.
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.
I'd rather be riding my '63 Triumph T120.
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.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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".
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
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.)
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.)
No, but the standards will be wildly different between an operating theater, a hospital ward, a visit to the general practitioner's office and first aid on a gushing wound. And for that matter how contagious it is, a cancer ward will only have basic sanitation while a virulent lung disease will be in full isolation. So no, there's not one answer that is perfectly right. But like you point out, there are many answers that are very wrong :)
Live today, because you never know what tomorrow brings
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.
Imagine coal miners who live on a continuum of the opinion that cleanliness is effective in increasing productivity. Which are right? Are any? Or should we be tolerant of OCD coal miners who cannot operate with dirty hands?
Just because you can type in an analogy does not mean it has any relevance.
What's the alternative? Full paragraph descriptions of each concept? Catch phrases catch on because succinctly convey meaning. There's nothing magical about either the phrases or the concepts behind them, but that doesn't mean the concepts are useless.
1. Never comment anything
2. Never document ever
3. Don't produce error messages and if you do be sure to use a number and not a human readable string
Unfortunately it seems that way to many software engineers write their code according to those 3 laws.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Agile means being conscious that the client *will want* to change the project requirements. This means making sure that the client understands that, and establishing a way to make it work.
And that is why you don't look surprised when you use Agile.
"Traditional" programming, on the other hand, is like making a map of a road with the client, and then getting in a car with him, start driving, and then refusing to turn the wheel even if there's a cliff just in front of the car "because it's not in the map that we agreed upon 2 months ago".
"Raenex"
Ugh.
English, for one. It is a very lively and expressive language. Terminology and shorthand serve to facilitate rapid communication within a given field. Renaming banal concepts to aggrandize them does not. It does pad the resume very nicely though.
You're somehow being obtuse and elitist at the same time. I didn't use these terms to sound smart. I used them to "facilitate rapid communication" within the field of "software engineering". I'm sorry if you find them distasteful, but that doesn't make them worthless.
It's funny you should write that since they are finding that over cleanliness is deadly.
Play Command HQ online
The image on the cover is M104: The Sombrero Galaxy. M104 is located in Virgo and is just under 30 million light-years from us. At it’s core is a supermassive black hole weighing in at about a billion solar masses.
...
The image of M104 on the cover is a combination of the famous visible light photograph from Hubble (right), and the recent infrared image from the Spitzer orbiting observatory (below, right). It’s the infrared image that clearly shows us the ring nature of the galaxy. In visible light we only see the front edge of the ring in silhouette. The central bulge obscures the rest of the ring. But in the infrared, the hot particles in the ring shine through the central bulge. The two images combined give us a view we’ve not seen before and imply that long ago it was a raging inferno of activity.
Tell us what you make of the above "explanation".
Questions raise, answers kill. Raise questions to stay alive.
There is a happy medium between making minor corrections as expected through the design and development of code, and completely redesigning the project every few days or weeks. Both traditional and agile approaches can be implemented well or can be implemented very very poorly. My experience has been that you start with fairly solid requirements and are flexible enough to make the darn thing work and if you have the time to also take advantage of any insights that come as the project progresses. However under no circumstances should you start off designing a bridge and end up designing an airliner. That isn't agile - it's moronic.
These posts express my own personal views, not those of my employer
Like all theoretical programming styles and religions, clean coding has one or two points to commend it but it would be impractical to follow it in every detail in real life. You'd end up with an unmaintainable mess of XYZArgument objects.
The programming community needs to attempt to not devolve into writing religious texts about how straight to sit up in your chair and what special underwear needs worn while programming. However, from a book writer's standpoint, a bible is certainly going to be a top seller if it catches on with enough adherents. So it's no suprise that this book pops up. The best advice to follow is to do what works best for you, but some people don't like that. So you get coders leaving on ships to go find places in the world where they can program as they see fit without the need fit someone's definition of 'clean.'
Unfortunately, managers will read this book and misinterpret it. Soon, we'll have more stupid fad rules like mandatory "stay out of the zone" breaks, mandatory walking around time, or mandatory whatever.
Look up Ignaz Semmelweis
The problem, Sir, is: here on slashdot nearly everyone is a kind of programmer. And like many programmers most of them are autodidacts (that does not exclude the option that they also visited an university and have a degree). ... well, that seems to be really bad in the USA e.g. Some new concept is suddenly talked about. In this case Agil. It gets ignored and ignored and ignored, but a noticeable amount of people have heard about it "somehow". After a while those guys "that have heard about it somehow" realize that there are suddenly books, trainings and consultants, coaches about that topic. They conclude the hype has started. On top of that they likely indeed meet a coach/trainer in a project who does not work to the expectation. The typical conclusion is: the whole concept is bullshit. /. readers/programmers use a version control system. Most of them likely use a xUnit like testing "framework". I would bet far over 50% have a nightly build or even a continuous build system. If they don't make a peer review before check in, most of them certainly check/read/look at the code when they integrate/merge into their local code base. I would assume that a lot of the /. readers (not to many but surely 30% or more) make more than one commit per day. And lots of them also write their own test cases. Etc. etc. ... so the conclusion was to fire one so that the inboxes of the others are full) /. crowd, as you are all so skeptical about everything new unless it is linux related, I would propose to read books about anecdotes (e.g. the Anit Pattern book) After all they usually dont' have new concepts which you need to grasp, agree with or disagree with but often simple funny eye openers. ...
However the simple idea that - instead of being an autodidact - having an experienced master as teacher and guidance is very strange to them. (There is nothing wrong in being an autodidact, ofc)
So basically everything "new" is an attack on their self acquired knowledge of truth and perception. An old friend of mine had a mantra: The perception is always the truth in the eye of the perceptee.
So what was the point I wanted to come to
The funny thing is: if you talk to those guys 10 years later, somehow they have adopted most of the "best practices" that where propagandize in that hype.
E.g. I would bet a huge amount of
That is Agil! Before the "hypes" you hate so much, you used back ups and not a source control system. You used a Word or Excel document and not bugzilla or another issue tracker. You did not write proper tests and you did not review code from other people.
Anyway, I for my part enjoyed the few talks I heard from you. E.g. two years ago in munich on the OOP you talked about how to make an organization more efficient. You fired Bob, poor Bob ^-^ But after that the throughput was much lower. (You had that picture of an inbox with "stuff to do" for everyone and the inbox always was only half full
Anyway: to the
I'm perhaps a nerd, but bottom line I only read 2 kinds of books: SF novels (Ian Banks!) and well written computer / software related literature. But in the later case mainly only "concept" work and not "how to learn language X or system Y". I find it quite entertaining to read such books while I'm sitting in the train to work
Good night.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.