Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Joshua Maurice]

On Aug 25, 1:44 pm, John Passaniti  wrote:
> On Aug 24, 9:05 pm, Hugh Aguilar  wrote:
>
> > What about using what I learned to write programs that work?
> > Does that count for anything?
>
> It obviously counts, but it's not the only thing that matters.  Where
> I'm employed, I am currently managing a set of code that "works" but
> the quality of that code is poor.  The previous programmer suffered
> from a bad case of cut-and-paste programming mixed with a
> unsophisticated use of the language.  The result is that this code
> that "works" is a maintenance nightmare, has poor performance, wastes
> memory, and is very brittle.  The high level of coupling between code
> means that when you change virtually anything, it invariably breaks
> something else.
>
> And then you have the issue of the programmer thinking the code
> "works" but it doesn't actually meet the needs of the customer.  The
> same code I'm talking about has a feature where you can pass message
> over the network and have the value you pass configure a parameter.
> It "works" fine, but it's not what the customer wants.  The customer
> wants to be able to bump the value up and down, not set it to an
> absolute value.  So does the code "work"?  Depends on the definition
> of "work."
>
> In my experience, there are a class of software developers who care
> only that their code "works" (or more likely, *appears* to work) and
> think that is the gold standard.  It's an attitude that easy for
> hobbyists to take, but not one that serious professionals can afford
> to have.  A hobbyist can freely spend hours hacking away and having a
> grand time writing code.  Professionals are paid for their efforts,
> and that means that *someone* is spending both time and money on the
> effort.  A professional who cares only about slamming out code that
> "works" is invariably merely moving the cost of maintaining and
> extending the code to someone else.  It becomes a hidden cost, but why
> do they care... it isn't here and now, and probably won't be their
> problem.

I agree. Sadly, with managers, especially non-technical managers, it's
hard to make this case when the weasel guy says "See! It's working.".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Joshua Maurice]

On Aug 25, 4:01 pm, John Passaniti  wrote:
> On Aug 25, 5:01 pm, Joshua Maurice  wrote:
>
> > I agree. Sadly, with managers, especially non-technical
> > managers, it's hard to make this case when the weasel
> > guy says "See! It's working.".
>
> Actually, it's not that hard.  The key to communicating the true cost
> of software development to non-technical managers (and even some
> technical ones!) is to express the cost in terms of a metaphor they
> can understand.  Non-technical managers may not understand the
> technology or details of software development, but they can probably
> understand money.  So finding a metaphor along those lines can help
> them to understand.
>
> http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
>
> I've found that explaining the need to improve design and code quality
> in terms of a debt metaphor usually helps non-technical managers have
> a very real, very concrete understanding of the problem.  For example,
> telling a non-technical manager that a piece of code is poorly written
> and needs to be refactored may not resonate with them.  To them, the
> code "works" and isn't that the only thing that matters?  But put in
> terms of a debt metaphor, it becomes easier for them to see the
> problem.

But then it becomes a game of "How bad is this code exactly?" and "How
much technical debt have we accrued?". At least in my company's
culture, it is quite hard.
-- 
http://mail.python.org/mailman/listinfo/python-list