Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not a real question by Mark Trapp May 11 '11 at 16:45

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

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. –  Eric Wilson 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" –  Jarrod Roberson 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? –  Carson63000 May 11 '11 at 22:03
add comment

6 Answers 6

up vote 18 down vote accepted

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.

share|improve this answer
9  
+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. –  Aaron McIver May 11 '11 at 14:39
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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