They are, but perhaps agile methods who diminish the importance of documenting have played against it. We will see what price we have to pay for this. In my e

They are, but perhaps agile methods who diminish the importance of documenting have played against it. We will see what price we have to pay for this. In my experience, people don't like to document, developers even more, and managers probably don't like to read documents, either. However, if people leave your company (something highly probable), how are you expected to train the new people? If you are working in a startup, that's not major problem: the startup may just die and you can have fun programming in the meantime. However, if there is company that intends to last more than a few years, ways of documenting your system are needed. IMHO, not using UML, or any other language, to think about our systems or even tell others how they work is a complete mistake. It is not only for telling others (colleagues and future workers) what the system does and why it does it that way, it is also to save effort and realize sooner that it will not work. So, whatever the case, training in how to explain your system to others is required. Call it UML or whatever. And, since UML is there, it may be worth to use it. It is not just the invention of a couple of mad engineers. You are free to use UML as you like. And do not need to use a huge tool. Text UML is a nice and refreshing way of looking at UML which I strongly recommend. Have a look at http://planttext.com http://planttext.com, for instance.