Capstone: Lessons Learned
I've now graduated and my fourth-year Capstone engineering project is long done. I wrote about the project while it was still in progress here. Now that it's over, I've been thinking about some of the lessons I learned from the experience. This list is by no means exhaustive.
One of the first lessons, one which I find myself learning and forgetting repeatedly, is that things will go wrong. There will be delays. Tasks will take more time than expected. Plan for this by being realistic about what you can accomplish and allowing for setbacks.
You've probably heard the phrase "a system is more than the sum of its parts". Unfortunately, this also seems to apply to a system's problems. The system's problems are greater than the sum of the problems of its constituent parts. For example, let's say you have two modules that seem to be bug-free. But when they are connected to form a larger system, things often go wrong at first. Incompatible interfaces, invalid assumptions, heisenbugs; the possibilities are many. This is hard to avoid, but one must be mindful that it can and will happen, and that time will be required to deal with it.
We had to scale down our expectations as the deadline drew nearer. The result was something like the following graph. Naturally, total progress toward the project increased with time. However, as the deadline approached, we realized that we could not possibly accomplish everything we set out to do by the deadline. We had this realization multiple times about multiple initial expectations.
As such, we had to scale back our expectations to more reasonable levels. Our rate of scaling back increased as the deadline approached, because the limitations imposed by the lack of time remaining became clearer. Of course, we could only scale back expectations so far to some minimum reasonable level. This is the level we should have been aiming for in the first place, though it wasn't apparent at the time.
As an aside, it may seem that the rate of progress should increase as the deadline approaches because you work harder to meet it. I found that this is roughly offset by the fact that the tasks being completed at that stage of the project are generally more difficult and thus require more effort.
Finally, the importance of a good relationship between team members cannot be overstated. Let's face it, no matter how hard you work, the most interesting and challenging projects cannot be completed by a single person or even a pair. You need your team.
I found that one of the most significant sources of disharmony among team members were differing expectations for the outcome of the project. We were particularly vulnerable because all of the members were ostensibly equal. Like most school projects, there was no clear hierarchy of authority. That means that there was no final word to settle disputes. I'm not saying that we should have elected a leader, but that it's important to recognise that democracy is hard and takes work. Clear communication of expectations and issues between all members on a continual basis is critical.
In hindsight, these lessons may seem pretty obvious, and, frankly, I agree that they are. But it is difficult to appreciate and learn to apply a lesson without experiencing it.