Things I don’t understand about Agile
I have been trying to learn Agile software development for the past several years and there are several things I don’t quite understand and I’m hoping people can enlighten me.
Why comments are evil?
This one I think I might understand to a degree. I agree with the idea that comments can very quickly get outdated and far removed from the code that they are suppose to comment. I also understand that if you write clean code then “what” comments are unnecessary. The thing I don’t understand is why this means that we should actively go through a code base and delete all comments? Or why we as developers should deride code that contains comments?
I personally think there is a place for “why” comments in a code base. I come across an odd bit of code, an odd business rule implementation, should I have to go and find the user story to find out why that particular odd decision was made? Or should I have a unit test explaining it: shouldDoThisBecauseIn1973BusinessMadeAOneOffDealWith...(). Where is the right place for this information to be captured? I would think that a story card would travel farther away from the code even faster then a comment.
Why design is evil?
This is probably my biggest pet peeve about Agile and the thing I really don’t understand. Why is design evil? We seem to have this idea that doing up front design before starting a story is not allowed. You cannot be doing XP if you do design, “design is waterfallish, we have organically grown code here.”
Personally, I think that in order to have well designed, clean, layered code, you need to do some design up front and you need some kind of architectural model to which your organically grown code adheres to. Otherwise, instead of lasagne, you get ravioli.
Why must you pair all the time?
I have already stated that I don’t really know how to pair and this is an outcome of that. I have heard of shops were if you are not pairing you are not coding. Heaven forbid that either you or your pair are ever sick. Are there no kinds of coding jobs that can be done by one person? Is there no benefit or place for a single programming sitting quietly in a room with the door closed focusing on a problem? What about all those studies that have been done about flow and the fact that open offices promote sickness and disease? What about a little privacy during the working day?
Why Agile principles become Agile rules?
This is the thing I don’t understand the most. Why is it that for many people and many shops, Agile principles become rules and the only way to do things? I have met people and worked in shops were they have Agile all figured out and any deviation is heresy. If you are doing Agile this one way, then you are unprofessional and a very bad programming. I always though that principles were just that principles, guidelines, starting points, rules of thumb. Things to be discussed, to be examined, and possibly bent or even broken when the situation calls for.
Isn’t one of the prime tenants of Agile the idea that we should analyze what we are currently doing and make it better. Doesn’t this mean things need to change? Or does it mean we are not disciplined enough in our adherence to one true path of Agile?
My understanding is agile says do “just enough” design and don’t over-design in anticipation (as it is assumptions-based). Lot of places that is being interpreted as no-upfront-design. Pair programming — not a big fan, but have seen people achieving some success with it.
No methodology is perfect (or close to it). One needs to pick the principles that work in their culture and environment.
Comments are evil?
Bad comments are evil, good comments are good … just like with code … and it shows … people who write beautiful code, also write robust comments that are valid for a long time.
Hi Chris, I think you hit the nail on the head in heading of the last paragraph:
“Why Agile principles become Agile rules?”
They shouldn’t be rules, and usually people that see them as such stop thinking for themselves, which is very dangerous.
I agree that “why” comment are a useful thing, and generally it is not a good idea to start deleting existing comments (especially in a legacy system that does not have well named methods, tests, and well factored design, comment can be essential). You should strive to make your new code self describing so you don’t have to use lots of comment going forward.
Likewise, a little white board design before starting is not bad, as long as you are willing to change it as you go.
I personally don’t pair very much, so I can’t really comment on that one, but again, words like always and never make me worry…
Evil in agile isn’t evil in other coding metaphors.
Evil in agile means something you don’t want to do. Avoid it if you can… but when you really need to do it then do it and do it right.
Comments are evil, because if you start allowing comments… then someone will come along and say you should comment all the code. Then before you know it you’re in a 2 hour meeting arguing over whether than comment should start with // or ///.
Comments are evil. Avoid them. Tell people not to use them.
Then when there is a really good time to use them… use them anyway.
—
Same with design. Design is evil. Tell people its bad and not to do it. Then when something actually does need to be designed before a project… do it anyway.
—
Pairing is absolutely required. Not pairing is evil. Tell people they should be pairing. Then when you’re doing some fiddly spacing exercise on a UI, go ahead and do it alone. Its trivial and doing it in pairs would just suck another productive person into the boring mess.
—
There are no rules in Agile. Just don’t ever admit to anyone else out loud..
My point of view when it comes to agile principles and whether to follow them or not, it’s all about risk management. We know about the positive and negative effects of applying the principles (or not) and if the team is willing to live with the consequences then that’s their decision.
For example: do we take the risk of less knowledge sharing by not pairing? Do we take the risk of diminished code quality by doing no upfront design at all?
If you don’ give examples when you make statements about Agile then you are just creating, then killing your own strawman.
Who said Design is evil and do they stand behind that statement or were they just spouting off? I don’t know of any “well respected” Agile artifact that says design is evil. I don’t think you will hear Martin Fowler, Bob Martin, or Kent Beck say it. How did “Agile” tell you that design is evil?
Same with not pairing. Where does one find out what the “Agile rules” are? Please tell me, because the manifesto is the only thing I know of that “defines” Agile and it does not call anything evil. It does not even recommend against doing ANYTHING. It only states the principles that a few guys found useful when trying to deliver software.
If you try a little harder you might find more constructive ways to pose your questions to the world.
Jeff Santini
But for what it’s worth, comments are evil
@ Robin – you encountered a captcha? I haven’t installed one, interesting. I will have to try posting a comment using Google Chrome.
@Jeff – Granted, examples would have helped. I provided some by way of some of the links. As for better examples, there are not attitudes that I have read on the web, they are attitudes I have encountered while working with people on agile projects.
I agree that Agile is a set of principles, none of which state that things are evil. However, I am not so sure the same can be said for implementations of Agile such as XP. Either way, it is amazing the amount of people I have met on projects have a very regimented approach to Agile.
For those who think design is evil, do things like creating layered architecture and ensuring your code adheres to things like Domain Driven Design fall under the category of design or creating clean code.
For me, they fall under both. I think you need to have some form of architectural design in place before you start coding. If you are creating a distributed system you need to know where you integration points are and how they will function. If you are creating a web application, you need to know how your tiers will be deployed and the integration points between them.
One project I worked on, there was no design done and consequently, the code was a mess. It had no layers and it was incredibly hard for even experienced developers to navigate the code base.
First off, comments are a *smell*. Comments in code indicate that the code is insufficiently clear — if you feel the need to write a comment then the code needs refactoring to be clear without it. Your example of a “why” comment does indeed belong in the test — if the code has to have particular behaviour in particular circumstances there should be a test for it, and the name of the test should be descriptive enough. If you still need a “why” comment, it should go with the test.
As for design being evil, I don’t think anyone would argue that. I think most agile proponents would advocate that we do design *all the time*. The idea is to try and get away from “design everything before coding” to “just enough” design for the tiny feature we’re doing right now, combined with refactoring to improve the design as we go along (and ensure we end up with lasagna where appropriate).
I almost never pair; mainly because I am the sole developer on most of my projects. Sometimes I make mistakes that I think a pair would have stopped me making. Sometimes I might ponder how to approach a problem for a while, and a pair might have helped reduce that time by thinking of an approach quicker. I haven’t enough experience pairing to confirm whether this is the case, but many people report plentiful benefits from pairing.
When it comes down to it, the principles are just that: principles. Agile methods such as XP provide concrete practices that embody those principles. I don’t think anyone would say you MUST do any particular practices. However, if you don’t do them, and you experience the problems they are intended to address it’s probably a good idea to try out the recommended practices.
Agile says nothing about open offices. Although, Agile environments encourage communication, and communication is hampered by closed-doors and cubicles.
If you are having issues with team and individual flow, then make sure there are core hours where everyone has multiple blocks of 2-3 hours of heads down time. A huge example of something that kills flow is a team that gets in between 7-9, and then does a standup at 10, and lunch at noon. The AM is wasted with interruptions to flow.
There is some trade-off of having the entire team in one room. Yes, there is some interruption to flow, but usually that interruption has to do with the project and is important for everyone to hear about. If there are a few people having off-topic conversations, they should leave the room, and go somewhere else where they won’t interrupt flow.
Our team closes the door every day. We don’t want the outside world interrupting our flow. Yet inside the room, the interruptions mostly have to do with our project, and usually worth-while.
Fair enough, I am sure there are plenty of bad instances of Agile projects.
I just have a pet peeve about principles getting the blame for things people do.
After all, democracy is not a bad idea just because America opened up Guantanamo.
Jeff
I thought I’ll be evil and post this comment. :p
I am glad that you are asking yourself these questions. I find it ironic how rigid people are on their Agile practices.
Comments in code don’t bother me. They are like Google ads to me now. Why do people have to make a big deal about them for? Haven’t they enabled the code collapse feature in their IDEs for comments?
I’m not a fan of big up front design. Keep it lightweight. Things where I believe some design should be done up front is UI work. Get a UX person in to create a good information architecture. You really can’t do this adhoc during a project. UI should be done up front because it will always get deprioritised during a project and left till the end, at which point a lot more effort is required to shift code around to handle the UI design.
I don’t get the pair all the time rule either. Just yesterday I found a defect that was written by a pair. It wasn’t found until the business started doing UAT. There were even unit tests all around it, so the pair were asserting the defect. The shared understanding in this case was flawed.
Keep questioning everything you do. Continuous improvement always begins with a question.
Chris, I can relate to that. I’ve blogged about agile fundamentalism yesterday:
The Decline and Fall of Agilists
http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html
If you think comments are evil, then you must really hate all the Java collections classes. In fact the whole of the .Net and Java runtimes must fill you with rage. There’s comments everywhere!!
Comments are not evil. Too many libraries don’t bother to explain their API because they’ve drunk the ‘no commments’ kool-aid.
For the sake of all the developers who will come after you, document your public API with class and method level javadoc COMMENTS! Children as yet unborn will thank you.