Comment by bbarnett
16 days ago
Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.
That's what's claimed. That's what people say, yet it's just an excuse. I've heard the same sort of excuse people have, after they write a massive codebase, then say "Oops, sorry, didn't get around to documenting it".
And no, hardware is not more difficult than software to document.
If the system is complex, there's more need to document, just as with a huge codebase. On their end, they have new employees to train up, and they have to manage testing. So any excuse that silicon vendors have to deal with such immense complexity? My violin plays for them.
> "Oops, sorry, didn't get around to documenting it".
That's obviously the wrong message. They should say "Go ask the engineering VP to get us off any other projects for another cycle while we're writing 'satisfying' documentation".
Extensive documentation comes at a price few companies are willing to pay (and that's not just a matter of resources. Look at Apple's documentation)
I write documentation as I'm writing the code. In my opinion, the code is only as good as its documentation -- they're two parts of the same thing. It's mostly comments at the top of files, and sometimes a markdown file in the same directory.
This way, good documentation is priced into my estimate for the project. I don't have a work item "spend a few days documenting." Nope, if I'm doing a foo then that includes documenting a foo at the same time.
> the code is only as good as its documentation
This heavily depends on your niche I think. If you're writing closed source vendor software and your client's only guiding light is your documentation, it's 100% true.
If you're working on a 5 people project that evolves at a fast pace, and everyone touching the code is expected to be familiar with the domain and operations, you'll mostly leave comments (todos, meta info, external ticket links etc), not documentation per se.
1 reply →
Documenting what is there usually is not the hard part (and AI is getting pretty good at that part btw).
Documenting how to use or interact with it in a specific context, which often includes perspectives on interactions with other components, or e.g. protocols not explicit in the code, deciding where to draw the lines of what can assumed trivial common knowledge and what should be specified or explicitly not specified without notices not to rely on these etc. , that is a different thing.
If it wasn't, then truly as they used to say, the source code would be it's own best documentation (I am a big fan of programming for readability, but even the best readable code, while it will be correct and up to date, will never be enough nor the best for all)
In my experience, coding is much faster when doing it this way.
Yes, you can produce a small amount of code faster if you don’t “waste” your time on documentation, but that becomes counterproductive as soon as you can no longer keep the entire codebase in your head.
With documentation one of the major hurdles is the maintainance. It is caring for a set of documents, created by people with different specializations, that describe the artefact from specific perspectives, but need to be kept in sync with the active creation and evolution of the artefact itself.
This is not impossible, but the effort and costs required are substantial and often lose out on a priority basis to just fixing or improving the product itself.
To clarify for me: Is this good or bad?
It's bad. Apple's documentation is notoriously weak, despite them being one of the most well-resourced companies in the world.
2 replies →
> If the system is complex, there's more need to document
It’s not first party documentation that’s the problem. The problem is that they don’t share that documentation, so in order to get documentation for an “unsupported” OS a 3rd party needs to reverse engineer it.
I find myself largely unable to document code as I write it. It all seems obvious at the time. It's when I go back to it later, and I re-figure it out, that the documentation then can be written.