Iteration 1

| No Comments

Overall, I would say that iteration one was a successful experience. I am
happy with our end product, not only because of its functionality but also
because of its design and general quality. Our scanner meets all stated
requirements, and all of our test cases pass. Furthermore, I would argue that
the design of our solution is fairly good. It seems to be flexible, and the
design held up well to modifications as our work progressed. To the best of my
knowledge, our code is properly and consistently formatted. Not all of the
iteration went smoothly, however. Our group encountered its fair share of
difficulties, especially as we neared the deadline. We had to do a substantial
amount of debugging near the end of the iteration to ensure that we were
passing all test cases, and we had to add several last-minute tests to confirm
that our scanner was adequately robust. In general, though, I think the
majority of our development process went very well and that our group can be
proud of its work.

My partner and I were able to work together very well, so we found it
easy to collaborate on the high-level design of the scanner and its components.
Even if only one of us was going to complete the implementation of a component,
we would both talk about its general design and the elementary aspects of its
implementation. This approach had several advantages, and I would definitely
recommend it to other groups. First of all, it allowed us to complete designs
much more quickly by bouncing ideas back and forth until we were satisfied.
This approach also ensured that both partners had at least a cursory knowledge
of the implementation of all components of the scanner. This would prove to be
very useful for debugging because both of us could investigate any problems,
instead of leaving the debugging solely to the person who implemented the
relevant component. Our approach to design also allowed us to effectively
divide up work. Because components were designed collaboratively, my partner
and I could both gauge the amount of work that each component would require and
determine the interdependencies between components.

Another effective practice our group used in iteration one was to
leverage object-oriented design to our advantage as much as possible. The
different pieces of our scanner implementation typically constituted their own
classes, which provided natural dividing lines for our work. We kept the
implementation of each class assigned to one person. This allowed us to use a
modular approach in our design of the scanner, and it also kept each of us out
of the other person's way as we were working. Another nice aspect of
object-oriented design is the fact that neither my partner nor I had to wait
for the other person to finish one of their components before we could
implement something ourselves. For example, my partner had to develop a
function that required a utility class I was expected to implement. In order to
prevent any problems, I committed a header file specifying the interface of
this utility class and a .cpp file containing stub implementations of all
necessary functions to our repository. This allowed my partner to continue
working without worrying about compiler errors while I was still finishing the
utility class. Once I was done, I simply updated the class's .cpp file in our
repository, which didn't affect my partner whatsoever.

I was also very pleased with the set of development tools I chose to use
for iteration one. I used a simple text editor to write all of my code, which I
found very useful for learning C++ syntax. I would recommend this approach to
anyone else who is still learning C++. I plan to avoid using an IDE until I
become more comfortable with the language. At least in my opinion, putting in
more work to learn C++ now will definitely pay off later. I also ran across a
particularly useful tool, called Meld, for viewing diffs. Meld makes it very
easy to view a diff graphically, with clear annotations about what has been
changed in each file. On my computer running Ubuntu, Meld could be installed
easily using apt-get. Once it's installed, you can type in "meld ." at the
terminal while in any directory under SVN version control. This command
launches a GUI that allows you to view all file modifications in that
directory. Another advantage of Meld is that it is already installed on the CSE
labs machines. If you are having trouble using SVN's command-line diff feature,
I would highly recommend trying out Meld. I found it particularly helpful to
view diffs of files I was about to commit, just to be sure I was aware of all
the changes I had made.

Unfortunately, my partner and I made some mistakes during the course of
iteration one. In hindsight, it is painfully obvious that we didn't put in
nearly enough work in the early portion of the development window. We ended up
doing a lot of work very close to the deadline, which was neither enjoyable nor
particularly effective. However, this was not a case of conscious
procrastination. My partner and I simply underestimated the amount of work that
iteration one truly involved. Furthermore, we didn't have a full understanding
of the requirements until the iteration deadline was fairly close. Part of this
was due to the fact that some aspects of the iteration specifications didn't
become more clearly defined (at least to us) until they were brought up on
Piazza in the few days leading up to the iteration deadline.

I also feel that my partner and I could have approached the writing of
unit tests a bit differently. We each wrote unit tests almost exclusively for
the set of classes that we had implemented ourselves. While this kept each of
us out of the other person's way, it also meant that we were only testing our
own code. It most likely would have been beneficial to make two major changes
to our process. First of all, I think we should have collaboratively developed
a few small unit tests for each component as we were designing that component.
This would have been very helpful in firming up the design of each component.
Secondly, I think we should have written a few unit tests for the components we
did not implement ourselves to further evaluate the general quality of our
code.

There are easy solutions to the other problems my partner and I
encountered. Obviously, we need to be more aggressive in the early portion of
the development window if we want to avoid doing an unreasonable amount of work
near the iteration deadline. In future iterations, I hope that we will be able
to finish our design and move into the construction phase fairly quickly. This
does not mean that we should spend less time in total on the design phase; it
just means that we should allocate more time to complete this task in the first
few days after the iteration specifications have become available.

Additionally, I believe we should attempt to finish the implementation
phase a few days before the iteration deadline. My partner and I ran into
trouble in iteration one because, by the time the deadline was getting close,
we thought we had completed a more substantial portion of the work than we
actually had. This problem can be easily avoided by making a serious effort to
finish up code construction and debugging earlier. This would give us more
flexibility in the last few days of the development window. Even if we make a
similar underestimation of work in a future iteration, we'll still have more
time to complete the remaining work than we did for this iteration.

For future iterations, I believe I will also need to be more active on
the class Piazza website. If some specification isn't clear to me, I plan on
immediately bringing it up on Piazza rather than taking the passive approach of
waiting to see if someone else raises my question later. This will hopefully
allow our group to get the vast majority of the implementation completed with a
couple of days to spare. Of course, it is likely that there will be other small
changes and clarifications to the requirements in the last few days of the
development window, but these should be a much smaller source of stress than
they were for iteration one if we are more proactive about understanding the
requirements and getting the implementation finished earlier.

Despite its difficulties, iteration one definitely went quite well. My
partner and I worked together smoothly, and we produced software that is
functional, well-designed, and formatted cleanly and consistently. Our design
process was effective, and our division of labor was fair and practical. Even
though we encountered problems, all of them have clear solutions that we can
use to make future iterations proceed more smoothly. While I didn't enjoy the
large amount of work our group had to complete close to the deadline, I would
be pleased if the next few iterations are as successful iteration one.

Leave a comment

About this Entry

This page contains a single entry by John Kolb published on March 8, 2012 5:30 PM.

Hello, World! was the previous entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Categories

Pages

Powered by Movable Type 4.31-en