I like the small iterations. I like the unit tests. I like code review. What I don't like is the starting off with little or no documentation. Am I alone in this? Do I simply have a misunderstanding of the process?

Any thoughts would be appreciated.

  • 2
    First of all, don't talk about the Agile methodology. The Agile movement is really a philosophy of development, that encourages adoption of a variety of practices and methodologies as appropriate. May 11 '11 at 15:57
  • 1
    "have a misunderstanding of the process?" -- yes
    – vartec
    May 11 '11 at 16:20
  • 2
    "The Agile methodology that must be strictly followed is not a true Agile methodology"
    – user7519
    May 11 '11 at 16:25
  • 1
    Hi Dan, there doesn't seem to be a solvable problem in your question, and questions like "I think/feel X, do others feel the same way?" are not on-topic here. If you have a specific problem that you need help with, feel free to ask about that.
    – user8
    May 11 '11 at 16:46
  • Everyone starts off with little or no documentation. The question is how you divide up your time between documentation and code - all the documentation first? Or only as much as you need to get started? May 11 '11 at 22:03

Remember, Agile doesn't mean no documentation, Agile means that you understand the "client" doesn't know everything they want so they can't give you a huge requirements doc that outlines everything. Agile advocates that you constantly talk to the client and say "Is this what you want?" or "How will X work when Y happens?" so together you create the requirements.

That said, no there's nothing wrong with you if you don't like a particular methodology. Most people seem to pick and choose various aspects of different methodologies anyways.

  • 10
    +1 Agile doesn't mean no documentation. People seem to think that it was Agile stands for; it's not. It values working software over comprehensive documentation; it does not negate the value in documentation. May 11 '11 at 14:39

The Agile Methodology states that you only do what you need at that time. If you want/need more documentation than is given, then that is a problem with the process, and it's not you. There are times when a lot of documentation is necessary for the project to continue. It's not counter to Agile to need this. You can't justify slacking off on requirements under the guise of Agile. This is actually a big problem that I've seen. A lot of people get lazy up front and chalk it off to the process. The real question needs to be asked, "Do the devs have what they need?" If the answer is no, then more work needs to be done.

Now this can be taken to an extreme, and someone can say, "Well I can't work on it unless the entire program is documented." At times this is true, but the team needs to take a look and see if this is really necessary.


I don't see why it would make you a bad programmer just because you don't like a particular methodology. It may make it hard for you to integrate with shops that implement it; that being said I have some doubts about how effectively it is implemented everywhere.

What makes you a bad programmer is bad code - facile I know - but you can like/be brilliant at all the methodologies all you like, and still be a bad programmer because your code isn't adequate.


The basic idea of Agile is that unless you have a gift of precognition, you cannot foresee far future. Thus you cannot document, what you cannot foresee.

That does not mean, you have no documentation at all. You do document technical design for current requirements (and of course you do document requirements themselves), and you do document current implementation. You're not expected to document how system will look after 10 more sprints, because you live in dynamic world, requirements might change.


I think you are misunderstanding the process. What documentation do you want? Before starting you need some sort of a goal. I start with use cases that I gather from conversations with my customer. I don't spend days making fancy diagrams. We talk, and then I write a Wiki page, and we go over that. Then I write some tests. Then I write some code.


There is an infinite combination of team sizes, domains, languages, personalities, budgets and requirements. There is no one methodology that is best for every situation. Similarly lots of people have personal preferences and styles.

Even if you dont like it its worth trying out new ideas a critically analyze the results. There are a lot of things I dont like, but after trying out for a while learn to love. Like Olives.

The other thing is fashions change regularly. I was brought up with Waterfall, I worked in a team that tried to do everything in Rational Unified Process which was the "best thing" at the time. Soon Agile will be replaced with something newer and better and no one will mention the Agile word again.

So dont feel like you need to like one methodology like Agile. (I personally dont like it) It doesn't make you a bad programmer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.