4 ms·

Ah, good old SWEBOK. There's a bit of history to this document. Most of us who started our careers in the last decade came up in a time of agile programming.

by jdlyga 6y ago

Ah, good old SWEBOK. There's a bit of history to this document. Most of us who started our careers in the last decade came up in a time of agile programming. Where code comes first and documentation is mostly just done before prod releases. The programming world wasn't always like this. The software engineering world has a pendulum that swings between "strict process" and "just write code", and right now we're pretty far into the just writing code camp. SWEBOK captures a lot of the push in the late 90s, early 2000s to make software engineering a licensed profession. Where most of the work would be done in UML diagrams and committees before any code was written. The thinking was that if the diagrams were thorough enough that the coding part would be trivial, almost like how blueprints are for building a house.

feoren 6y ago
And then everyone realized that the blueprints for the house are not the UML diagrams, but the code itself. Documentation is done at the same time as the code is written, because the code itself is the authoritative documentation about how to build the program and what it will do. If the pendulum does swing back, let's hope those strict processes operate on code this time, instead of on silly code-adjacent time-wasting activities.
- biofox 6y ago
  As someone who tends to conceptualise code visually, I find it extremely helpful to sketch-out diagrams of the processes and organisation before getting anywhere near the keyboard -- drawing clarifies my thinking unlike anything else. As such, I find the top-down UML-first approach to be much more natural, but I seem to be in the minority on this.
- HeyLaughingBoy 6y ago
  The problem with this response is that the the "code itself" is not the authoritative documentation of what should be done. The "code itself" is what was done and could be absolutely, completely wrong. The point of separating documentation and code is that the assumption is that the documentation (design) is correct, having been reviewed and the code should implement it correctly, correctness being verified by review and testing. Those strict processes should absolutely operate on code, but they are useless if they operate only on the code.

by jdlyga 6y ago

feoren 6y ago

And then everyone realized that the blueprints for the house are not the UML diagrams, but the code itself. Documentation is done at the same time as the code is written, because the code itself is the authoritative documentation about how to build the program and what it will do. If the pendulum does swing back, let's hope those strict processes operate on code this time, instead of on silly code-adjacent time-wasting activities.

biofox 6y ago
As someone who tends to conceptualise code visually, I find it extremely helpful to sketch-out diagrams of the processes and organisation before getting anywhere near the keyboard -- drawing clarifies my thinking unlike anything else. As such, I find the top-down UML-first approach to be much more natural, but I seem to be in the minority on this.
HeyLaughingBoy 6y ago
The problem with this response is that the the "code itself" is not the authoritative documentation of what should be done. The "code itself" is what was done and could be absolutely, completely wrong. The point of separating documentation and code is that the assumption is that the documentation (design) is correct, having been reviewed and the code should implement it correctly, correctness being verified by review and testing. Those strict processes should absolutely operate on code, but they are useless if they operate only on the code.