3 ms·
Way back when in 2006 I attended this talk as a budding sw engineer http://www.dfjug.org.br/Merson06_JavaOne.pdf http://www.dfjug.org.br/Merson06_JavaOne.pdf
by palidanx 13y ago
Way back when in 2006 I attended this talk as a budding sw engineer
http://www.dfjug.org.br/Merson06_JavaOne.pdf http://www.dfjug.org.br/Merson06_JavaOne.pdf
Two questions asked to the speaker afterwards still resonate with me to this day (below are my notes)
Q1: How much should you document?
This question came up after the session, and he said you should document as much as necessary for your stakeholder. Documenting any more would be overkill.
Q2: Question the value of your artifacts.
What this guy also said was to question the value your artifacts are doing. If no one is reading the artifacts, then something is wrong with this picture.
- tucaz 13y agoI agree with both answers. I think that UML is one of many available options to document your stuff. The funny thing is that, like many other things, UML was specified in a way that is not practical to be followed 100% so people use it as they see fit and that's ok. The other important point is to take into account your stakeholders. Developers (myself included) are also stakeholders so in many situations I create documentation for my future-self since it's the best way to remember that was the context at the time or how that weird stuff that is ran once in a while is done.