Book Review: The Clean Coder 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 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 |
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.
Clean Coders (Score:4, Funny)
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 (Score:5, Interesting)
Re: (Score:3)
Re: (Score:2, Funny)
If that run-on explanation was an example of your "copious documentation," then I believe you just proved the GPs point.
Re: (Score:3)
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 s
Re: (Score:2)
Re: (Score:2)
Upon further reflection I think sloppy code can be attributed to laziness.
Laziness to think but, unfortunately, not too lazy to write code.
Re: (Score:2)
Stands to reason: character traits (of which tidyness is just one) are usually reflected in everything a person does. So yes, I believe strongly that you can judge people's approach to work ethics by observing other areas of their lives. I get my best observations during game nights: are they prone to cheat, do they use sneaky tactics, how competitive are they and how well do they cope with losing, how serious do they take the game, what's the general vibe they give off while playing, ...
OTOH, I seem to con
Re: (Score:3)
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.
Re: (Score:2)
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?
Before jumping into writing the code, I find better to think again: do I really need that code? Do I need it there (or in another place)?
In my case taking a shower (or anything else to keep me away from the temptation of the keyboard), is as good a way as any others (e.g. having a smoke outside).
Let me summarize (Score:5, Insightful)
Programming--You're doing it all wrong!
all wrong? Re:Let me summarize (Score:3)
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 wit
Re: (Score:2)
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.
Re: (Score:2)
1) Do you write clean Code? Is it maintainable? Is it readable? What is the spaghetti rating? Are your functions/classes nested to deep?
By what metrics? I've never seen a metric that's truly a good indicator for a wide variety of code.
2) Can you re-write the code from just the comments? Is it self documenting?
If you need so many comments that you have duplicated your code completely as comments, your comments are inappropriate. Comments should explain the intent of your code. They should refer to algorithms, not re-describe them in their entirety. For example: Formulae should not be duplicated in comments - if the developer can't read a formula as code, they should not be permitted to modify it! - but a description of variables is (that is if the names aren't self explanatory, or the formula isn't so common any expert should be able to read it. For example commenting Newtonian motion formulae like F=ma and s=ut+0.5at^2 isn't appropriate), the intent of the formula is important, the algorithms used are important, references to design documents are important.
3) Is is 'Done', complete, FIN? If you have any technical debt then it is NOT DONE.
If you're putting out incomplete code as a finished product, it doesn't matter what techniques or methodologies you use, you shouldn't be permitted to code.
4) What percentage of the code is covered by your test cases? anything less than 80% is IMHO unclean.
I've seen code with 80% inappropriate coverage. Not only is the code not properly tested, but the coder has wasted additional time on test cases that are not useful - time that should have been spent writing better code (including better tests). Metrics like this are no more sophisticated or appropriate than the old kloc measure of performance. There is no substitute for proper code review (including the test cases). I'd rather 50% coverage with proper tests than 80% coverage with bad tests.
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'.
Nope. I think I've demonstrated - with the exception of code completeness and within the limits of what you'd expect of a slashdot post - why these things are neither necessary nor sufficient.
If you want to write good code your first port of call is to have a second person that wasn't involved in writing it do a proper review. That's exceedingly hard because even the best read code is hard to walk into. That is nonetheless what needs to be done. Formal processes should only be used as a guidelines. If you want to see how horribly badly over-formalising and over-prescribing can go take a look at ISO9001. Software and methodologies must not be treated like religion. It is part engineering and part science - no magic required.
Re: (Score:2)
Technical Debt (Score:2)
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: (Score:2)
Jeff Atwood has a post about technical debt: http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html [codinghorror.com]
here, have some cynicism (Score:2)
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: (Score:3, Interesting)
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: (Score:2)
Maintaining standards of aesthetics in your code is the cheapest and easiest way to ensure it does what it's supposed to do. Simple logic: if I have a hard time reading your code, I might misunderstand its intention and modify it the wrong way.
Re: (Score:3)
I have another phrase for you then: "spaghetti code". I hope you like pasta.
Appropo... (Score:2)
Bump this [youtube.com] while yo checkin' yo braces and semicolons...
Quality (Score:2)
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: (Score:2)
Re: (Score:3)
... 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: (Score:2)
... 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
Re: (Score:2)
Test driven design does not prevent or catch logical errors. It only helps prevent errors that come about from code not adhering to spec. If the specification itself is logically incorrect, then there is no way to write a test suite that will catch that.
For instance, if the spec says "When A and B are both true, do essential function C" but in reality A implies ~B, it doesn't matter how awesome your test suite is, or how much coverage it has - your code will pass whatever tests you want to throw at it, but
Re: (Score:2)
For instance, if the spec says "When A and B are both true, do essential function C" but in reality A implies ~B, it doesn't matter how awesome your test suite is, or how much coverage it has - your code will pass whatever tests you want to throw at it, but in practice C will never be executed.
Then your test suite is shit. Any test case should start with verifying the preconditions (and not actually execute the test code unless preconditions are not met). If A implies not B, a test case well constructed will always be "in error" (not failing the product to be tested, but the test environ execution).
Re: (Score:2)
I love unit tests as much as the next refactoring junkie, but there are very significant areas in quality assurance that TDD should not and cannot address, for instance software with emergent behavior.
I've been the unlucky maintainer of monstrous "unit tests" that were instead huge fixtures that create an alternate universe to production. Devs would write code, then spend as much time or more getting the "unit tests" to work, then have QA find brand-new bugs.
The TDD response is decomposition, but some solut
Re: (Score:2)
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.)
You have to pay for clean. (Score:5, Insightful)
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: (Score:2)
"...pick two."
If you're lucky or very good. In lots of projects, you get to pick just one. ..bruce..
Re: (Score:2)
LOL too true!
Usually that one is "Cost" in my experience.
Re: (Score:2)
"...pick two."
If you're lucky or very good. In lots of projects, you get to pick just one. ..bruce..
More often than I like, you finish in picking none.
Re: (Score:2)
It's always Speed and Cost where I am. I wish it was ever quality.
Re: (Score:2)
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 seri
Re: (Score:2)
While I agree with you about primary businesses, most software isn't developed for the software industry. For example, where I work might not have the primary business of programming, however they still do it in house and to a larger extent outsource it. The outsource WILL have their primary business as programming, however they will be subject to the unreasonable demands of the corporation. Which usually means features fall off the table at the sake of cost, etc... So by extension, being at the behest of t
Re: (Score:3)
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: (Score:2)
Touche. But you get the idea.
Re: (Score:2)
Well said, sir.
Re: (Score:2)
The problem with software development in large corporations is not that managers demand Mennonit
Re: (Score:2)
The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.
Who will win in the market? Whoever can get Angry Birds out in two months, even though it crashes now and then, or those who take six months to deliver the same functionality with fewer (but never no) crashes? You know the answer to that as well as I do. As far as insight goes, I tend to value Dick Gabriel's "Worse is Better" paper over anything that "Uncle Bob" has written.
The fact that Uncl
Re: (Score:2)
Who will win in the market? Whoever can get Angry Birds out in two months, even though it crashes now and then, or those who take six months to deliver the same functionality with fewer (but never no) crashes? You know the answer to that as well as I do. As far as insight goes, I tend to value Dick Gabriel's "Worse is Better" paper over anything that "Uncle Bob" has written.
Not sure if you're criticizing your parent, because you just made his point. Making Angry Bird with bugs quicker means the manager didn't pick all three.
Re: (Score:2)
I will tell you how to break this rule. Most people order 30 chairs and sit on 2 of them. They have all sorts of reasons why they need those 30 chairs: People might come over, some might break, somebody might break in a steal some of them. But in the end, they really only use 2 of them. So we spent 15 times more than we needed in both time and cost. And in the bargain, because we couldn't afford 30 *good* chairs, we made crappy ones. The crappy ones break over time and we have the added cost of dealin
Re: (Score:2)
This attitude is why software is so bad, lulzsec [twitter.com] can go around owning just about any company it wants purely for the lulz.
Good thing we don't treat our bridge builders like we treat our the designers and builders of our software infrastructure. Then people would die instead of just losing millions of dollars.
I've been programming for over 20 years... (Score:2)
Re: (Score:2)
Re:I've been programming for over 20 years... (Score:5, Interesting)
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: (Score:2)
There is an important distinction between refactoring and rewriting. Refactoring is the task of changing small parts of the code so that it operates exactly the same way that it did before. Your outward facing interfaces aren't going to change much in each refactoring (although after successive refactorings it might change dramatically). Your unit tests should still run (possibly with some updating) after you have refactored the code.
Rewriting is the task of taking a large piece of code and rewriting it
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
This is true (Score:2)
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
Re: (Score:2)
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, prog
I found this sentance odd. (Score:2)
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
Re: (Score:2)
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 o
Re: (Score:2)
Re: (Score:2)
Your boss has already been to sales-, er, business school and is thinking "We're on it! We'll succeed!" from the git-go. If you don't say "We'll try", the boss will find someone else who will. But then I suppose a book on craftsmanship is mostly useful to those who are able and willing to target the "high-end" of the coding job market where, presumably, a person can have strong principles and employment at the same time.
3 companies, 3 agile failures (Score:4, Interesting)
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: (Score:2)
Agile is like "flexible" -- it's just another word thrown around that enables enough ambiguity to allow people to have it both ways.
Re: (Score:2)
"Agile" is a virtually meaningless phrase: People over Processes, etc, etc. What *exactly* does that mean? I've worked on some extremely good "Agile" teams. All of them have had well documented processes and extremely disciplined practitioners.
The number of groups who prefer ad hoc development far and away outnumber the number of groups who prefer disciplined development. Ad hoc isn't even necessarily "bad". It's just "as you go". If you've got a team composed of great people, it can work. But, this
Re: (Score:2)
In general, I agree with you. No methodology is a silver bullet that will magically transform a bunch of mediocre people into a tight, intelligent productive team. In fact, I would go so far as to say that most methodologies exist to mitigate the effects of the mediocre. A really good team of people can produce great code no matter what methodology is presented to them (even if they have to work around bits of it sometimes).
I successfully introduced Agile development into my last organisation, which was
Re: (Score:2)
That isn't Agile development - it's just poor development. Good agile development doesn't cede control of the development process from developers to customers, any more than good waterfall takes control away from customers and gives it to developers.
In both cases, it requires strong product management - and this is not undertaken by the customers or the developers in either case. Taking scrum as an example, you have the role of product owner, whose job it is to ensure that the right things are being built
Re: (Score:2)
I totally agree with what you say. Agile is not the absence of planning. You still have to do a lot of requirements gathering and analysis. Some architectural issues need careful spiking to ensure you will meet non-functional requirements.
Agile is not anarchy - it's about controlled and collaborative change in exploring a complex problem space.
Never.. (Score:2)
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 D
Hippocratic Oath (Score:2)
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: (Score:2)
To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm".
I just wish that "Uncle Bob" would take the same care with the software engineering profession.
Re: (Score:2)
Is the book based on research? (Score:2)
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.
Re: (Score:2)
Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?
Neither.
Re:Is the book based on research? (Score:5, Informative)
Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?
As the author, I feel able to respond. This book is a book about how to behave as a professional programmer. It is not a book about how to write code. As such it is not, and could not be based on any kind of scientific research. Rather it is based on my 40+ years of experience as a programmer, and on the mistakes I have made over that time. This book contains all the things I wish I had known when I was in my thirties.
Another way to look at this... (Score:2)
"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.
I half jokingly say there's 3 laws to programming (Score:2)
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.
Dogma (Score:2)
Re: (Score:3, Informative)
Re:Agile... please stop. (Score:5, Funny)
Re: (Score:2)
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
Re: (Score:2)
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 und
Re:Agile... please stop. (Score:5, Insightful)
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 (Score:2)
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: (Score:2)
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: (Score:2)
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 :)
Re: (Score:2)
It's funny you should write that since they are finding that over cleanliness is deadly.
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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."
Re: (Score:2)
Kudos for posting her Uncle Bob. I've seen one of your 'shows'. The only thing I can say is 'Sport On the Nail'.
Re: (Score:2)
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: (Score:2)
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;
Re: (Score:2)
I saw some open source the other day riddled with gotos.
Not intrinsically bad. Code generators (e.g flex/bison) generate goto-s and there is no problem.
Re: (Score:2)
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.
Re: (Score:2)
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 a
Re: (Score:2)
I think there's a critical distinction, though. Let's start with a support beam. If I correctly account for all the loads and select a strong enough beam, and then I don't exceed design tolerances on the beam, we expect the beam not to fail. It may fail, but that'll be because it was damaged or something happened to force the load out of spec or something.
Challenger was a different matter. It was the equivalent of using a support beam that was only 95% strong enough for the load placed on it. When you do th
Re: (Score:2)
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 r
Re: (Score:2)
Or gone and given an unofficial technical briefing to the men and women flying in the Challenger. Or even camped out on the launchpad.
The fact is that the engineers *could* have stopped the launch that day. But they didn't think they could, because it would require them to do something dangerous and extreme -- they would have to rock the boat in a major wa
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
"Raenex"
Ugh.
Re: (Score:2)
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".