Loading ...
Sorry, an error occurred while loading the content.

Re: KISS

Expand Messages
  • SirGilligan
    ... work well. At the end of the subject they can code quite well, they understand testing, and they have had to develop a number of interesting algorithms.
    Message 1 of 17 , Jun 29, 2005
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Clark, David"
      <david.clark@c...> wrote:

      > As part of my end of semester reflection, I think that some things
      work well. At the end of the subject they can code quite well, they
      understand testing, and they have had to develop a number of
      interesting algorithms. One area, however, that is generally not done
      well is simplicity. Their code works, but it is often a lot more
      complex than it needs to be. Especially if the algorithm is a bit
      difficult.

      So, the goal is to /teach/ what is simple code.

      What is simple code? Following you try to define it with points.
      Let's continue to there.

      >
      > Students adapt to how assignments are marked. So I am thinking that
      next time I run it I will try to incorporate a "simplicity" component
      in my marking scheme. Here is the idea. Award 10 marks (points if you
      are US), say, for simplicity in each assignment question. Then they
      would get simplicity marks from the formula
      > 10 * base_simplicity_measure / their_simplicity_measure
      > where base_simplicity_measure is the simplicity measure on my
      solution.
      >
      > So what to use for the simplicity measure?
      > It must be simple, effective, and appropriate for beginning
      students.
      > Here is my suggestion (aim is to be as low as possible) :
      > 1 point for each IF
      > 2 points for each IF .. ELSE or case (or conditional).
      > 1 point for a loop
      > When a loop or selection statement is nested [1, 2, 3, ...]
      deep, there are additional [1, 3, 5, ...] points.
      >

      IF statements and ITERATION (loops) statements are equal.
      IF ELSE and SWITCH/CASE (Or generally SELECTION) statements are equal.
      Nested loops and selections are more costly.

      What about Recursion?
      What about GO TO's?
      What about in-line assembly?
      What about Global Variables?
      What about Magic Numbers?
      What about comments? Do comments reduce the number. A comment is
      worth -1 points?


      > The hoped-for benefits of having this component in their marks
      include
      > more emphasis on simplicity
      > an awareness that there are other solutions than the one they
      first come up with
      > encourages modularity
      > encourages use of library functions
      > students start to learn about refactoring
      >
      > I would appreciate any comments you have on this idea,
      > thanks,
      > David
      >

      I think we should stick to the original goal as I took it:
      "So, the goal is to /teach/ what is simple code."

      I think the definition of simple code in this case should be:
      "Code that is easy to read, that clearly reveals its intent, and
      works correctly."

      Since experience is the only teacher that I know that can teach
      simple code I suggest that you give some examples of code that is not
      simple and code that is simple (both the simple and non-simple work
      correctly!) and discuss the differences. You may find that your
      students may offer alternative solutions that they feel are simple
      and you do not. It is about their experience level.

      Now that you have shown some examples and discussed it with them make
      your assignments. When grading each student's solutions give them a
      simplicity score of some kind and write it on their code printout.
      Have each student then write on the code printout a justification for
      why the feel it is simple OR let them refactor the solution for
      another attempt. If they take the justification approach re-grade the
      solution and send it back. Granted you might give it the same grade
      as before. They can justify again or refactor. If the take the
      refactoring approach re-grade the solution and send it back. Continue
      this iterative approach until the student gets a grade they are
      satisfied with or the semester ends.

      I think school is about learning and a grade should reflect what the
      student knows and has done at the end of the grading period. If a
      student finally figures everything out in the last week then that
      student should get a 100% or an "A" or whatever your grade scale
      gives!

      Just some thoughts.

      Geoff
      M.S. Computer Science, BYU.
      (I taught a couple of 400 level classes)
    • Doug Swartz
      ... I like this a lot. Rank order forces the students to exercise judgement (you are required to compare rather than giving everybody else, in the class a
      Message 2 of 17 , Jun 29, 2005
      • 0 Attachment
        Wednesday, June 29, 2005, 5:39:56 PM, Ron Jeffries wrote:

        > What if the students themselves were to rank order the solutions in
        > terms of simplicity, //as a group//? They don't get any pizza until
        > they agree. Meanwhile, you guide the discussion so that they address
        > and assess things as concretely as possible.

        I like this a lot. Rank order forces the students to
        exercise judgement (you are required to compare rather than
        giving everybody else, in the class a great score because you
        want them to like you). Requiring consensus will force the
        very discussion of "what is simple" that can lead to learning.

        Bill's idea of treating this as extra credit points is also
        very good. Do something like give 10 points to the top 25% of
        the ranked entries and 5 points to the 2nd 25%.

        --

        Doug Swartz
        daswartz@...
      • SirGilligan
        ... in ... until ... address ... This is reminiscent of a performance review in industry. I have some strong opinions about preformance reviews and maybe
        Message 3 of 17 , Jun 29, 2005
        • 0 Attachment
          --- In extremeprogramming@yahoogroups.com, Doug Swartz
          <daswartz@p...> wrote:
          >
          > Wednesday, June 29, 2005, 5:39:56 PM, Ron Jeffries wrote:
          >
          > > What if the students themselves were to rank order the solutions
          in
          > > terms of simplicity, //as a group//? They don't get any pizza
          until
          > > they agree. Meanwhile, you guide the discussion so that they
          address
          > > and assess things as concretely as possible.
          >
          > I like this a lot. Rank order forces the students to
          > exercise judgement (you are required to compare rather than
          > giving everybody else, in the class a great score because you
          > want them to like you). Requiring consensus will force the
          > very discussion of "what is simple" that can lead to learning.
          >
          > Bill's idea of treating this as extra credit points is also
          > very good. Do something like give 10 points to the top 25% of
          > the ranked entries and 5 points to the 2nd 25%.
          >
          > --
          >
          > Doug Swartz
          > daswartz@p...


          This is reminiscent of a "performance review" in industry.
          I have some strong opinions about preformance reviews and maybe they
          are applicable to this situation.

          http://home.att.net/~geoffrey.slinker/maverick/MaverickReviews.html

          A key point would be that each student ranks every other student's
          work AND they rank the assigment as well, thus ranking the teacher.
          If the student's all feel the teacher's assignment was poor in
          someway they can have the assignment thrown out.

          Maybe this is applicable, maybe it is a shameless plug. Let's do a
          review to figure it out. ;-)


          Geoff
        • Jonjon Limjap
          I suggest you give emphasis to maintainability rather than simplicity. As Doug stated in his email, simplicity is in the eye of the beholder.
          Message 4 of 17 , Jun 29, 2005
          • 0 Attachment
            I suggest you give emphasis to "maintainability" rather than "simplicity."
            As Doug stated in his email, simplicity is in the eye of the beholder.
            Maintainability on the other hand emphasizes on code being more manageable
            rather than taking on the assumption that simple code is more manageable.

            Emphasis on "simplicity" might encourage your students to do "crazy" things
            like uneccessarily unrolling loops, keeping themselves from using objects
            (yes, some programmers define simplicity that way) and using a plethora of
            variables instead of using arrays. (Refer to http://www.thedailywtf.com for
            such examples)

            I think that by emphasizing on maintainability instead, you would be able to
            do your students (and their future employers/employees) a great favor.

            -Jon

            On 6/29/05, Clark, David <david.clark@...> wrote:
            >
            > This isn't strictly XP, but as a group you are so helpful and interested
            > in programming that I am sure some of you will take an interest in this.
            > Apologies to the others.
            >
            > I teach an introductory programming subject to students who are doing a
            > more technically oriented IT course. The language of implementation is C,
            > under Linux. (These students also do another, gentler, introductory
            > programming subject using VB .NET.) The subject is highly algorithmic. It
            > has a high emphasis on testing.
            >
            > As part of my end of semester reflection, I think that some things work
            > well. At the end of the subject they can code quite well, they understand
            > testing, and they have had to develop a number of interesting algorithms.
            > One area, however, that is generally not done well is simplicity. Their code
            > works, but it is often a lot more complex than it needs to be. Especially if
            > the algorithm is a bit difficult.
            >
            > Students adapt to how assignments are marked. So I am thinking that next
            > time I run it I will try to incorporate a "simplicity" component in my
            > marking scheme. Here is the idea. Award 10 marks (points if you are US),
            > say, for simplicity in each assignment question. Then they would get
            > simplicity marks from the formula
            > 10 * base_simplicity_measure / their_simplicity_measure
            > where base_simplicity_measure is the simplicity measure on my solution.
            >
            > So what to use for the simplicity measure?
            > It must be simple, effective, and appropriate for beginning students.
            > Here is my suggestion (aim is to be as low as possible) :
            > 1 point for each IF
            > 2 points for each IF .. ELSE or case (or conditional).
            > 1 point for a loop
            > When a loop or selection statement is nested [1, 2, 3, ...] deep, there
            > are additional [1, 3, 5, ...] points.
            >
            > The hoped-for benefits of having this component in their marks include
            > more emphasis on simplicity
            > an awareness that there are other solutions than the one they first come
            > up with
            > encourages modularity
            > encourages use of library functions
            > students start to learn about refactoring
            >
            > I would appreciate any comments you have on this idea,
            > thanks,
            > David
            >
            >
            > ============ Examples ============
            > Example 1: Max of 3 numbers (a very early illustrative example, before
            > they have done loops).
            > if (a > b)
            > if (a > c)
            > max = a
            > else
            > max = c
            > end
            > else
            > if (b > c)
            > max = b
            > else
            > max = c
            > end
            > end
            > This gives a simplicity measure of 8. An experienced programmer would
            > generate a solution with a simplicity measure of 2.
            >
            > Example 2: Median of 3 numbers (again a very early illustrative example,
            > before they have done loops).
            > This is a fun example in class, as most students' solutions have holes in
            > them. Finding examples where students' solutions fail reinforces testing.
            > Students' solutions are certainly not simple.
            > In this case the base simplicity measure is 3.
            >
            > Example 3: A real example. A question from the students' final assignment.
            > The base simplicity measure for this question is 10.
            > Card Shuffle
            > You have 3 tables, table 1, table2 and table3. There is a line of cards on
            > table1. Table2 and table3 are empty. Each card has on it a single digit in
            > the range [1..9], so that the line of cards makes up a number.
            > You wish to place the cards on table3 so that they make as large a number
            > as possible. You are allowed the following moves.
            > a) Take the rightmost card from table1 and place it at the rightmost end
            > of the cards on table3.
            > b) Take the rightmost card from table1 and place it at the rightmost end
            > of the cards on table2.
            > c) Take the rightmost card from table2 and place it at the rightmost end
            > of the cards on table3.
            > For instance if 869 was on table1, then the sequence of moves abac would
            > give the number 986 on table3. If 8679 was on table 1, then the sequence of
            > moves abac would give the number 9687 on table 3. Note you can do better
            > than that in this example.
            > Examples
            > input: 869 -> output: 986
            > input: 8679 -> output: 9867
            >
            >
            >
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com <http://objectmentor.com>
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >


            [Non-text portions of this message have been removed]
          • Doug Swartz
            ... I also thought of a stack ranking performance review when I read Ron s suggestion. I don t personally believe in stack ranking of people for performance
            Message 5 of 17 , Jun 29, 2005
            • 0 Attachment
              Wednesday, June 29, 2005, 7:33:36 PM, SirGilligan wrote:

              > --- In extremeprogramming@yahoogroups.com, Doug Swartz
              > <daswartz@p...> wrote:
              >>
              >> Wednesday, June 29, 2005, 5:39:56 PM, Ron Jeffries wrote:
              >>
              >> > What if the students themselves were to rank order the solutions
              > in
              >> > terms of simplicity, //as a group//? They don't get any pizza
              > until
              >> > they agree. Meanwhile, you guide the discussion so that they
              > address
              >> > and assess things as concretely as possible.
              >>
              >> I like this a lot. Rank order forces the students to
              >> exercise judgement (you are required to compare rather than
              >> giving everybody else, in the class a great score because you
              >> want them to like you). Requiring consensus will force the
              >> very discussion of "what is simple" that can lead to learning.
              >>

              > This is reminiscent of a "performance review" in industry.
              > I have some strong opinions about preformance reviews and maybe they
              > are applicable to this situation.

              I also thought of a stack ranking performance review when I
              read Ron's suggestion. I don't personally believe in stack
              ranking of people for performance review purposes. However, I
              think stack ranking of software solutions in this case is a
              good idea. In some ways having a consensus ranking of the
              software solutions is like your Maverick performance review.


              --

              Doug Swartz
              daswartz@...
            • SirGilligan
              ... than simplicity. ... beholder. ... manageable ... manageable. ... do crazy things ... objects ... plethora of ... http://www.thedailywtf.com for ... be
              Message 6 of 17 , Jun 29, 2005
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, Jonjon Limjap
                <jonlimjap@g...> wrote:
                > I suggest you give emphasis to "maintainability" rather
                than "simplicity."
                > As Doug stated in his email, simplicity is in the eye of the
                beholder.
                > Maintainability on the other hand emphasizes on code being more
                manageable
                > rather than taking on the assumption that simple code is more
                manageable.
                >
                > Emphasis on "simplicity" might encourage your students to
                do "crazy" things
                > like uneccessarily unrolling loops, keeping themselves from using
                objects
                > (yes, some programmers define simplicity that way) and using a
                plethora of
                > variables instead of using arrays. (Refer to
                http://www.thedailywtf.com for
                > such examples)
                >
                > I think that by emphasizing on maintainability instead, you would
                be able to
                > do your students (and their future employers/employees) a great
                favor.
                >
                > -Jon
                >

                I agree! Hear hear!

                I have often contemplated how I would teach a 200 or 300 level
                programming class. I thought I might do something like this:

                Devise a product that is to be developed over several iterations
                during the semester.

                Each piece builds upon the other. Each assignment builds towards the
                final product. It would have to be carefully designed to give the
                desired results.

                Intentionally make the first User Story some simple yet essential
                piece just like you would do in the real world. Then add the features
                you want and also change the performance constraints. Have the
                automated release tests ready, as the teacher I would code those up
                during the summer or between semesters. Suppose one of the iterations
                developed a simple piece with no performance requirements. Then in
                the next iteration change the requirements and add the refactoring of
                that piece for the iteration. Man, you could really teach a lot about
                the real world. In conjunction with performance requirements changes
                you could switch maybe a logging piece from using a flat file to XML
                and then finally to an SQL database. All kinds of stuff! Sounds fun!
                Through this maybe you could continue it on to another related class,
                like a 342 and 343 class or something. You could show how patterns
                help out. This could really prepare one to come out of the gate well
                ahead of the competition. It is exciting to think of the
                possibilities.

                Geoff
              • SirGilligan
                ... solutions ... they ... Yep.
                Message 7 of 17 , Jun 29, 2005
                • 0 Attachment
                  --- In extremeprogramming@yahoogroups.com, Doug Swartz
                  <daswartz@p...> wrote:
                  >
                  > Wednesday, June 29, 2005, 7:33:36 PM, SirGilligan wrote:
                  >
                  > > --- In extremeprogramming@yahoogroups.com, Doug Swartz
                  > > <daswartz@p...> wrote:
                  > >>
                  > >> Wednesday, June 29, 2005, 5:39:56 PM, Ron Jeffries wrote:
                  > >>
                  > >> > What if the students themselves were to rank order the
                  solutions
                  > > in
                  > >> > terms of simplicity, //as a group//? They don't get any pizza
                  > > until
                  > >> > they agree. Meanwhile, you guide the discussion so that they
                  > > address
                  > >> > and assess things as concretely as possible.
                  > >>
                  > >> I like this a lot. Rank order forces the students to
                  > >> exercise judgement (you are required to compare rather than
                  > >> giving everybody else, in the class a great score because you
                  > >> want them to like you). Requiring consensus will force the
                  > >> very discussion of "what is simple" that can lead to learning.
                  > >>
                  >
                  > > This is reminiscent of a "performance review" in industry.
                  > > I have some strong opinions about preformance reviews and maybe
                  they
                  > > are applicable to this situation.
                  >
                  > I also thought of a stack ranking performance review when I
                  > read Ron's suggestion. I don't personally believe in stack
                  > ranking of people for performance review purposes. However, I
                  > think stack ranking of software solutions in this case is a
                  > good idea. In some ways having a consensus ranking of the
                  > software solutions is like your Maverick performance review.
                  >
                  >
                  > --
                  >
                  > Doug Swartz
                  > daswartz@p...


                  Yep.
                • Dave W. Smith
                  ... and in Perl, since There s More Than One Way To Do It : @score = (0, 0, 0, 0); # or @score = qw(0 0 0 0); # or @score = (0) x 4; Dave
                  Message 8 of 17 , Jul 2, 2005
                  • 0 Attachment
                    Keith Ray wrote:
                    > In C, C++, Java:
                    >
                    > int score[4] = { 0,0,0,0 };

                    and in Perl, since "There's More Than One Way To Do It":

                    @score = (0, 0, 0, 0); # or
                    @score = qw(0 0 0 0); # or
                    @score = (0) x 4;

                    Dave
                  • Anthony Williams
                    ... int score[4]={0}; Will do the trick in C++. Anthony -- Anthony Williams Software Developer
                    Message 9 of 17 , Jul 4, 2005
                    • 0 Attachment
                      Keith Ray <keithray@...> writes:

                      > In C, C++, Java:
                      >
                      > int score[4] = { 0,0,0,0 };

                      int score[4]={0};

                      Will do the trick in C++.

                      Anthony
                      --
                      Anthony Williams
                      Software Developer
                    • Kevin Wheatley
                      ... well the problem I have with this is that if you switched to floating point scores this might still work, but leaves you with a problem if you find your
                      Message 10 of 17 , Jul 4, 2005
                      • 0 Attachment
                        Ian Collins wrote:
                        > Or the simplest form:
                        >
                        > memset( score, 0, sizeof(score) );
                        >
                        > Would that score high for simplicity, or low for obscurity?
                        >
                        > To an experienced programmer, it is clear, efficient and concise, to a
                        > novice more than a little cryptic. The joys of C.

                        well the problem I have with this is that if you switched to floating
                        point scores this might still work, but leaves you with a problem if
                        you find your self with non IEEE floats on any particular platform.
                        Your making an assumption about the underlying representation in
                        memory of the types. Whilst its correct most of the time its poor in
                        terms of robustness.

                        This would be pretty poor C++ code especially with templates (generics
                        in Java) making that switch to float real easy.

                        Kevin
                        --
                        | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this |
                        | Senior Technology | My employer for certain |
                        | And Network Systems Architect | Not even myself |
                      • Steven J. Owens
                        ... As a quick aside, I prefer clarity to simplicity. Clarity is something that is easier to point at than simplicty. Even if you can still disagree on
                        Message 11 of 17 , Sep 8, 2005
                        • 0 Attachment
                          > Wednesday, June 29, 2005, 12:59:47 AM, Clark, David wrote:
                          > > I teach an introductory programming subject to students [...]
                          > > So what to use for the simplicity measure?

                          As a quick aside, I prefer "clarity" to "simplicity." Clarity is
                          something that is easier to point at than simplicty. Even if you can
                          still disagree on whether something is clearer or not, you can at
                          least discuss more usefully why or how it's clearer or not.

                          My rationale is that the more clearly the programmer's intent is
                          expressed in the code, the better the compiler can optimize. And
                          generally the compiler's optimizations will be better than any that I
                          have time/energy/smarts to add... until I measure and find that it's
                          not good enough, in which case I'll do a more rigorous performance
                          analysis. Add in here the usual arguments against early optimization
                          and the usual advice on the right way to do optimization :-).

                          On Wed, Jun 29, 2005 at 06:30:50AM -0500, Doug Swartz wrote:
                          > [...]
                          > Simplicity is truly in the eyes of the beholder. The only
                          > reason simplicity is important, is because, unlike code written
                          > for college courses, code written for industry is usually read
                          > many more times than it is written. Thus it is dependent on
                          > the experience, skill, and biases of the reader.
                          >
                          > You could look at using some of the automated complexity
                          > calculation algorithms: cyclomatic, essential, .... I'm not a
                          > fan of these, but they're, perhaps, better than nothing.
                          >
                          > Another approach is Steven's suggestion to have the students
                          > rate each other's work for simplicity. It is subjective, but
                          > it's a good approach because, as noted above, the goal of
                          > simplicity is "in the eye of the beholder". I

                          Does it have to be rated on each project? Maybe follow up each
                          project with a review of a solution turned in for the previous class,
                          and an examination of how the code could have been simplified and
                          refactored. If you want to be brave, you could use a solution from a
                          current student, but I'd be wary of the emotions & politics that could
                          introduce :-).

                          Or you could make it an extra credit assignment - given this
                          solution to the project you last completed, what change would be the
                          best way to improve the clarity of the code. Best suggestion gets
                          five extra points.

                          --
                          Steven J. Owens
                          puff@...

                          "I'm going to make broad, sweeping generalizations and strong,
                          declarative statements, because otherwise I'll be here all night and
                          this document will be four times longer and much less fun to read.
                          Take it all with a grain of salt." - http://darksleep.com/notablog
                        Your message has been successfully submitted and would be delivered to recipients shortly.