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.

The Decline and Fall of Agilists
http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

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.

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

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.

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.

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

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

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