"TL;DR: Source code is the blueprint for software."
...and the 2x4s are the blueprint of a house and
the steel beams are the blueprint of the skyscraper....
I'll take the TL;DR at face value since it was written by the author. The statement completely obliterates the entire concept of a blueprint or plan. By that reasoning, it is true everything is its own blueprint, and the concept has no meaning (of course this is a standard tautology).
And, simply nodding to CYA documents (for when the customers/end users come back saying that your product doesn't do X), or to docs for when formal proofs are needed, doesn't cover the concept.
The point of planning (or blueprinting) is to think about what you are going to build before you get out the tools, abstracted away from the specific tools that you'll use, and to then record and communicate those thoughts to all the stakeholders. It doesn't have to be a complete formal, engraved-in-stone blueprint, but a modest amount of actual thinking and planning goes a loooong way.
I've often found that with a little thought, we'll use a different tool than originally expected. If you expect to just dive in and sort it out in your source code, then you've already a priori restricted your choice of tool, and probably also your library, algorithm, etc. (of course if you only have or know one tool then, well, 'everything looks like a nail and who needs a blueprint?').
Without planning, you'll get what grows out of the first thing that comes to mind, not the best thing you could build. The mere fact that it manages to run or stand is not a defense of the bad process.
Planning is where the real thinking takes place. Sure, if all you want to do is exercise your programming skills and avoid thinking, then don't plan. But don't pretend that no one else should think or plan, or complain when someone else presents a plan to which you are expected to build (and don't be surprised 10 years on when you don't advance as far as you expected).
...and the 2x4s are the blueprint of a house and the steel beams are the blueprint of the skyscraper....
I'll take the TL;DR at face value since it was written by the author. The statement completely obliterates the entire concept of a blueprint or plan. By that reasoning, it is true everything is its own blueprint, and the concept has no meaning (of course this is a standard tautology).
And, simply nodding to CYA documents (for when the customers/end users come back saying that your product doesn't do X), or to docs for when formal proofs are needed, doesn't cover the concept.
The point of planning (or blueprinting) is to think about what you are going to build before you get out the tools, abstracted away from the specific tools that you'll use, and to then record and communicate those thoughts to all the stakeholders. It doesn't have to be a complete formal, engraved-in-stone blueprint, but a modest amount of actual thinking and planning goes a loooong way.
I've often found that with a little thought, we'll use a different tool than originally expected. If you expect to just dive in and sort it out in your source code, then you've already a priori restricted your choice of tool, and probably also your library, algorithm, etc. (of course if you only have or know one tool then, well, 'everything looks like a nail and who needs a blueprint?').
Without planning, you'll get what grows out of the first thing that comes to mind, not the best thing you could build. The mere fact that it manages to run or stand is not a defense of the bad process.
Planning is where the real thinking takes place. Sure, if all you want to do is exercise your programming skills and avoid thinking, then don't plan. But don't pretend that no one else should think or plan, or complain when someone else presents a plan to which you are expected to build (and don't be surprised 10 years on when you don't advance as far as you expected).