Design Attitudes

@Dale

I have to say your answer was pretty cool, as I learned some interesting
things from it. I always like the historical perspective. The only part
I'd comment on is this:

"As a software system evolves the assumptions that were made early on
are no longer valid,"

To which I'd say: "Yea, but the code doesn't seem to go away." You'll notice that images never seem to get smaller.

(Yes, Cuis. I see you.)

I can remember several times this year when I was looking at Seaside code, particularly 2.6, where I was finally
understanding things that I thought were tied were actually separate and one was redundant. I'm thinking particularly
the evolution from the Builder to the Canvas. They were both there. One was unnecessary. And the way some projects
evolve, the classes proliferate creating a similar kind of pollution. Granted, if I had a solid grip on patterns,
I might not mind so much. But I don't think that invalidates my preference.

Let me be clear: I admire Lukas and his work. I think Gofer would be great in Squeak. I discovered, as a result of this
bust-up, his tutorials about PetitParser, which I'm going to spend time on. But I reserve the right to encounter code,
turn away from the computer, and scream. But that's just me. The more explicit we can be about our preferences, the
better I think we can all get along.

Chris

On 17 December 2010 20:19, Chris Cunnington
<[hidden email]> wrote:
My 2c.

I am always wanted to have some guru who routinely checks my code,
 analyzing it, and letting me know if there any shitty stuff.
We should stay open to criticism. Otherwise we will stop learning at
some moment,
because pride turns you into stone.

> Chris
>

--
Best regards,
Igor Stasenko AKA sig.

It's one of the drawbacks of distributed development that all of the
developers working together can't get into a conference room and "yell
at each other" every once in awhile.

I know that at times I need to be hit over the head with a 2x4 before I
get it....But that's difficult to do over email, developers in the same
room can let off some steam and then get down to business and come to an
understanding (usually).

It's not easy to make reasonable arguments in 140 characters and
sometimes it's not easy to come to a technical compromise via email....

After a "heated discussion" and resolution, it's easier to give and take
constructive criticism.

Dale

On 12/17/2010 12:54 PM, Igor Stasenko wrote:
>
> My 2c.
>
> I am always wanted to have some guru who routinely checks my code,
>   analyzing it, and letting me know if there any shitty stuff.
> We should stay open to criticism. Otherwise we will stop learning at
> some moment,
> because pride turns you into stone.
>

This expression is worth more than two cents, Igor.

On Dec 17, 2010, at 12:54 PM, Igor Stasenko <[hidden email]> wrote:

(big snip)

Chris,

You've reminded me of another of my sayings.

You know the phrase about the bride wearing "something old, something
new, something borrowed, something blue"?

Well I've thought for a very long time that every release of software
should include "something _rewritten_, something new, something
borrowed, something blue":)

It's always been hard to convince a manager that you'll spend the next
several months working on the new release where your goal is that
nothing has changed (externally), but you've restructured in preparation
for the new round of features and done something about the accumulated
cruft ...

It's also hard to convince a developer to spend time working on
something old instead of something new:)

The idea of mixing up a release with a little bit of rewrite and little
bit of new is that you don't have to spend all of your time on the old...

Dale

On 12/17/2010 11:19 AM, Chris Cunnington wrote:

Igor Stasenko wrote:
>
> My 2c.
>
> I am always wanted to have some guru who routinely checks my code,
>  analyzing it, and letting me know if there any shitty stuff.
> We should stay open to criticism. Otherwise we will stop learning at
> some moment,
> because pride turns you into stone.

And you don't even need a 'guru', but a committed team. At my previous
job (@ CaesarSystems), every change had to be reviewed by another team
member. That was true even for the boss and the technical leader. The
reviewer could be any team member (except the author of the change set).
The reviewer checks that the code is sound, that it doesn't break
anything obvious (or any existing test), and that the mandatory tests
fail without the fix and pass with it. But the reviewer could simply
reject the code for not liking it, or not fully understanding the
intent. Some times, when agreement became difficult (author would defend
his original version, reviewer would keep rejecting it), a full team
meeting was done. In these, most people would have learned something
valuable after the discussions, and many times, better designs would emerge.

This is also great to have a consistent coding style that is the Team's
one, and not a coder's own. Code review is also a great opportunity to
make team members learn about parts of the system they never worked on,
and it avoids concentrating specific knowledge on a single person.

This practice was the single main factor resulting in high code quality
and a team with ever increasing skills. It is indeed what I miss most of
that job.

Nowadays I code mostly alone, and the only way to emulate that practice
is to review my own code one or two days after I write it. It works:
many times I find errors, details I forgot to consider, or unwanted
consequences. For instance, most of the change sets in the Cuis update
stream get rewritten several times over several days, until I'm
satisfied with them.

Cheers,
Juan Vuletich

Hurray Igor!

Testing can never replace code review. The Wikipedia article on software peer review reports: "The National Software Quality Experiment,[2] evaluating the effectiveness of peer reviews, finds, "a favorable return on investment for software inspections; savings exceeds costs by 4 to 1". To state it another way, it is four times more costly, on average, to identify and fix a software problem later."

I suspect that the figure is much higher if it is left to the end user to find the problem.

But this requires, of course, that the code is readable and chunkable so that there is something to review.

Cheers-
-Trygve

On 2010.12.17 23:52, Juan Vuletich wrote:

Igor Stasenko wrote:

My 2c.

I am always wanted to have some guru who routinely checks my code,
 analyzing it, and letting me know if there any shitty stuff.
We should stay open to criticism. Otherwise we will stop learning at
some moment,
because pride turns you into stone.

And you don't even need a 'guru', but a committed team. At my previous job (@ CaesarSystems), every change had to be reviewed by another team member. That was true even for the boss and the technical leader. The reviewer could be any team member (except the author of the change set). The reviewer checks that the code is sound, that it doesn't break anything obvious (or any existing test), and that the mandatory tests fail without the fix and pass with it. But the reviewer could simply reject the code for not liking it, or not fully understanding the intent. Some times, when agreement became difficult (author would defend his original version, reviewer would keep rejecting it), a full team meeting was done. In these, most people would have learned something valuable after the discussions, and many times, better designs would emerge.

This is also great to have a consistent coding style that is the Team's one, and not a coder's own. Code review is also a great opportunity to make team members learn about parts of the system they never worked on, and it avoids concentrating specific knowledge on a single person.

This practice was the single main factor resulting in high code quality and a team with ever increasing skills. It is indeed what I miss most of that job.

Nowadays I code mostly alone, and the only way to emulate that practice is to review my own code one or two days after I write it. It works: many times I find errors, details I forgot to consider, or unwanted consequences. For instance, most of the change sets in the Cuis update stream get rewritten several times over several days, until I'm satisfied with them.

Cheers,
Juan Vuletich

Trygve,

Thank you for continuing to contribute to our community!  I find great value in the wisdom of your experience.  And it's nice to know that long-time users still have faith in Smalltalk.

Sean