The most important thing I learned was that anytime I assume any sort of
leadership position, I should take a more active role in executing it. I found
that the key areas in which I could have improved were in project planning
(specifically, encouraging more structured analysis of problems and
intermediate tasks) and the actual execution of the project (ensuring that
work is high-quality and done on time).

It has become painfully clear to me just how important it is to conduct
in-depth planning. This made itself clear not only in our failure to notice
that our architecture was fundamentally unworkable, but also in the somewhat
unrealistic timing estimates we made. Although in this particular case it
would most likely not have been possible to find the part of the code which
caused the limitation, this is not necessarily true of other
projects. Problems of this type can often be avoided through careful planning,
saving untold hours of work.

Planning also is helpful in analyzing how to break up tasks into intermediate
goals. There were a few problems within our group with making sure everyone
had neither too little nor too much work assigned. However, one of our major
problems was that we didn't do enough research into the finer details of the
project. Rather, we chose some larger tasks which seemed to fit together
fairly obviously, but without actually looking into them more deeply we didn't
know how realistic our timing estimates would be or how applicable the
subgoals were. For instance, we were significantly set back by delaying our
decision to remove floating point code; we saw the value of this removal to be
primarily in speeding up the code, and speed was one of our lower-priority
goals, so we avoided it. More detailed research would have made it clear much
earlier on that removal of floating point code was necessary, and we would
have had more than two weeks to accomplish that task.

Regarding execution, I found that I was not nearly assertive enough in
enforcing group deadlines. Some of the group members have given me feedback to
this effect. The importance of making and meeting deadlines cannot be
overemphasized. Only as May 3 came critically close did I make the following
clear to the group: It is not an acceptable excuse that work could not be
completed due to its taking unexpectedly long, because technical work always
takes longer than expected, and this should have been accounted for. I found
that taking this rather inflexible approach to deadlines had a positive effect
on completion, and the project would most likely have gone better if I started
using this approach earlier.

Interestingly, I find that these leadership lessons are also applicable to my
own work: When I work on a large project (or a large piece of an even larger
project) I should do my homework and analyze exactly what I need to do. This
will have a profound effect on my performance and ability to complete the
project, just as it does in a group setting. Similarly, I should refuse to
let myself miss deadlines. Admittedly, this is a tough one to enforce, but
once I realize that missed deadlines cannot be blamed on lack of foresight, I
should be on schedule much more often.