Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
From a (dev)ops perspective, if I had a vendor hand me a tarball instead of proper documentation, I’d look very far away from their company. It isn’t a matter of if shit goes wrong, but when. And when that shit goes wrong, having comprehensive documentation about the architecture and configuration is going to be a lot more useful than having to piece it together yourself in the middle of an outage.
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
This is the most accurate description of anything that’s ever been written.
Or create a better UI that doesn’t require so much documentation.
This assumes front-end development.
From a (dev)ops perspective, if I had a vendor hand me a tarball instead of proper documentation, I’d look very far away from their company. It isn’t a matter of if shit goes wrong, but when. And when that shit goes wrong, having comprehensive documentation about the architecture and configuration is going to be a lot more useful than having to piece it together yourself in the middle of an outage.
Yeah, I almost added a clarification for that very point, and see now that I should have.
Sacrilege!! /s
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Definitely. Most often it’s people misunderstanding the “a over b” of agile as “never do b”.