[Tutor] Pair 'o dimes wuz: Volunteer teacher

[avi.e.gross at gmail.com]

Alan,

Good points. I find a major reason for a published design is to highlight
easily what CANNOT and SHOULD NOT be done.

Too often people ask for new features or other changes without knowing (or
caring) if it can be done trivially, or not at all, or perhaps would require
a set of new designs/requirements followed by a complete rewrite, perhaps in
another language.

It can be something as simple as pointing out how the code has a function
that takes TWO arguments and the new feature would require adding a third.
In some languages that can be as simple and in others it might mean
searching all existing code and adding some harmless third argument for all
cases that do not want or need it, and recompiling everything in sight and
hoping you did not miss anything or break something else. Ditto for making
one argument optional but with a default.

Now in python, some things like this may be easier to change. But my point
is asking a program to do something it was not designed to do is easier to
refuse to accept when you can show how it clashes with the design. Yes, they
can still ask for it, but cannot expect to get it soooooon.


-----Original Message-----
From: Tutor <tutor-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of
Alan Gauld via Tutor
Sent: Sunday, July 24, 2022 9:05 AM
To: tutor at python.org
Subject: Re: [Tutor] Pair 'o dimes wuz: Volunteer teacher

On 24/07/2022 12:23, Leam Hall wrote:

> First, Python is a lot easier to read than many languages. 

True but that only really helps when working at the detail level. It does
nothing to help with figuring out how a system works - which functions call
which other functions. How  data structures relate to each other etc. And
thats where design comes in. One of the big failures in design is to go too
deep and try to design every line of code. Design should only go to the
level where it becomes easier to write code than design. When that stage is
reached it is time to write code!

> Imagine the dev team trying to work through a spaghetti of undesigned 
> codebase, and the design person saying "Now do you believe me that 
> design is important?"

I've been there several times. We once received about 1 million lines of C
code with no design. We had a team of guys stepping through the code in
debuggers for 6 months documenting how it works and reverse engineering the
"design". it took us 3 years to fully document the system. But once ew did
we could turn around bugs in 24 hours and new starts could be productive
within 2 days, rather than the 2 or 3 months it took when we first got the
code!

When I ran a maintenance team and we took on a new project one of the first
tasks was to review the design and if necessary update it (or even rewrite
it) in a useful style. A good design is critical to efficient maintenance,
even if it has to be retro-fitted.

> Unfortunately, we can't just open our skulls up, drop in the GoF or 
> Booch's OOAD, and magically do good design.

Absolutely true. You need to start with the basics.
Branching, loops, functions, modules, coupling v cohesion.
Separation of concerns, data hiding. Clean interface design.
Then you build up to higher level concepts like state machines, table driven
code, data driven code, data structures and normalisation.

And even if using a book like Booch (which is very good) it should be woked
through in parallel with the language constructs.
But just as reading booch alone would be useless, so is learning to define
functions without understanding their purpose. Or building classes without
understanding why.

Learning is an iterative process. And this is especially true with software.
But you need to understand the why and how equally. Learning how without
knowing why leads to bad programming practices - global variables, mixing
logic and display, tight coupling  etc.

> Once we have the basics, hopefully a mentor shows up

Ideally we have the mentor in place before we even look at the basics.
Even the basics can be baffling without guidance.
I've see so many beginners completely baffled by a line like:

x = x + 1

It makes no sense to a non-programmer. It is mathematical nonsense!
(Its also my many languages have a distince assignment operator:

x := x+1

is much easier to assimilate....

> We agree that good design is good. My opinion, even if it's mine 
> alone, is that design is not the first thing to learn.

I dont think I'm arguing for design as a skill - certainly not things like
UML or SSADM or even flow charts. But rather the rationale behind
programming constructs. Why do we have loops?
Why so many of them? And why are functions useful? Why not just cut 'n paste
the code?

For OOP it's about explaining why we want to use classes/objects.
What does an OOP program look like - "a set of objects communicating by
messages". How do we send a message from one object to another?
What happens when an object receives a message? What method does the
receiver choose to fulfil the message request? How does the receiver reply
to the requestor? These ideas can then be translated/demonstrated in the
preferred language.

A decent OOAD book will describe those concepts better than a programming
language tutorial in my experience. (Again, the first section of Booch with
its famous cat cartoons is very good at that)

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor