"I don't know where people are learning this, apart from generic "life lessons" of perfectionism drilled into them when they were very young."
I left university teaching about 15 years ago, but I always had to fight the old guard of every faculty I worked for on that issue for every programming class I ever taught.? Even the ones who did understand?my points said it was too hard for students to learn good software design without having them do a good design for fixed assignment requirements before writing any code (like making students turn in an outline before writing their papers).? Even if we grant that premise (which I do not), waterfall just being an artifact of teaching skills in isolation gets ingrained as to how to develop software.
On Wed, Jul 26, 2023 at 9:08?AM George Dinwiddie <lists@...> wrote:
On 7/26/23 9:25 AM, J. B. Rainsberger wrote:
> On Wed, Jul 19, 2023 at 3:55?PM Vaughn Cato via
> <> <vaughn_cato=[email protected]
> <mailto:[email protected]>> wrote:
>
>? ? ?One thing that helped me with design by using TDD was how it
>? ? ?encourages making constant changes to the code. It makes changes
>? ? ?necessary because you haven't thought too far ahead, and it makes
>? ? ?changes safe because of the quality of the tests and how fast you
>? ? ?can run them. Because you are constantly changing the code, this
>? ? ?leads to wanting to find ways to make those changes easier, and code
>? ? ?that is easy and safe to change strongly overlaps with well-designed
>? ? ?code. Reducing coupling and increasing cohesion is one of those
>? ? ?things that you find makes code easier to change.
>
>
> This is perhaps one aspect of Evolutionary Design in general that I
> emphasize: it normalizes changing code; it helps reverse the belief that
> changing code is a failure of prediction and that there is a "first
> time" to "get it right".
>
> I recently sidestepped an argument on Reddit about this. It had been a
> long time since I'd encountered someone who genuinely believed that one
> must always get the design right the first time and every other way to
> work is wrong. They framed it as something like "Why would you waste
> time building it the wrong way just so that you can build it the right
> way later?!" They seemed unable to see that it might not be possible to
> see "the right way" and "the wrong way" in advance or that those labels
> might change or that those labels are not helpful in the first place.
>
> I don't know where people are learning this, apart from generic "life
> lessons" of perfectionism drilled into them when they were very young.
A lot of traditional approaches treat any need to change the code as
evidence of a defect. Back around the start of the century, someone told
me they were following Watts Humphrey's Personal Software Process (PSP)
and were counting every time they hit the backspace key as a defect they
had corrected.