3 ms·

I can always read source code. Any programmer worth a damn can. Docs are out of sync with the code the second the code changes in any non-trivial way. However,

by junon 6y ago

I can always read source code. Any programmer worth a damn can. Docs are out of sync with the code the second the code changes in any non-trivial way. However, code always documents how it works (sometimes poorly, of course).

jameshart 6y ago
I'll take that as a yes. So I wonder how you feel about: Individuals and interactions VS processes and tools Customer collaboration VS contract negotiation Responding to change VS following a plan
- junon 6y ago
  They're all important. I don't really see the point in chosing one or the other.
  - water8 6y ago
    You have to pick one or the other when choosing your development strategy. If you focus on customer collaboration, you could end up giving away too many freebee features that should have been feature requests and billed. If you have a design iteration plan, how do you respond to a showstopper that makes the plan infeasible if you are on a strictly waterfall design plan? Each has it's trade offs so you can't always pick one or the other willy-nilly or else you don't have a design strategy at all
rhodozelia 6y ago
The code I write is going to be used for 20-30 years, and then when the platform is replaced I assume someone will read the code to see what they have to do to get the system working on the new platform. I have documentation for end-users and documentation for maintenance / troubleshooters and zoomed out documentation that explains the problems and approaches taken, and sometimes justifying any tradeoffs. If code is temporary then it might not be worth the effort to document, but my documentation is what everybody except one person 20 years from now sees along with the user interface, so for my application the code doesn’t matter and the documentation matters quite a bit!
- junon 6y ago
  I was more referring to how the code works and development practices/codebase layout/etc, not end-user documentation.

by junon 6y ago

jameshart 6y ago

I'll take that as a yes. So I wonder how you feel about: Individuals and interactions VS processes and tools Customer collaboration VS contract negotiation Responding to change VS following a plan

junon 6y ago
They're all important. I don't really see the point in chosing one or the other.
- water8 6y ago
  You have to pick one or the other when choosing your development strategy. If you focus on customer collaboration, you could end up giving away too many freebee features that should have been feature requests and billed. If you have a design iteration plan, how do you respond to a showstopper that makes the plan infeasible if you are on a strictly waterfall design plan? Each has it's trade offs so you can't always pick one or the other willy-nilly or else you don't have a design strategy at all

rhodozelia 6y ago

The code I write is going to be used for 20-30 years, and then when the platform is replaced I assume someone will read the code to see what they have to do to get the system working on the new platform. I have documentation for end-users and documentation for maintenance / troubleshooters and zoomed out documentation that explains the problems and approaches taken, and sometimes justifying any tradeoffs. If code is temporary then it might not be worth the effort to document, but my documentation is what everybody except one person 20 years from now sees along with the user interface, so for my application the code doesn’t matter and the documentation matters quite a bit!

junon 6y ago
I was more referring to how the code works and development practices/codebase layout/etc, not end-user documentation.