Coding Notes

Last semester I took Software Engineering Principles (the precursor to the senior experience class) in the middle of the semester my professor gave a mini lecture on low hanging fruits and how to accomplish things in projects.  One of the things he emphasized was that in the middle of projects it can seem that there isn’t much work to be done, of if there is it’s really lengthy work.  In theory the problem is that while working through projects things can come to a stand still because team members are afraid of doing duplicate work and so no one does any work.  The problem with this of course, is that then nothing gets done.  My professor described two ways of dealing with this, grabbing low hanging fruits, and just doing it.

Low hanging fruits are basically the easy to grab small(er) tasks that just need to be done, but aren’t necessarily the most important task.  The nice thing with low hanging fruits is that even though they may not be all that important they do need to get done and so they provide a lot of exposure.  Some examples might be putting the initial empty Documents in the repository just to get it up there, writing the simple interface prototype, and writing up meeting notes.  In my notes I wrote down that low hanging fruits are the parts of a project that are low risk, low energy, and high impact with the return of high visibility.  The low risk part means that the low hanging fruits are things that would eventually get done anyways, but its nice when other people do them (high exposure).

So while low hanging fruits are important they wont finish the project, what will finish the project is making sure that things get done.  Getting things done in a project means writing the same requirement as someone else, designing the same prototype, and essentially doing duplicate work from time to time.  But this is important because it allows for ambiguity to be rooted out.  So low hanging or not jumping into doing work that needs to be done is important to prevent a stand still, and you wont always be doing duplicate work.

One of the things that I’m finding in my senior project is that a lot of the low hanging fruits are also some of the most important parts of whats going on.  This may have something to do with the fact that we are following a risk based model, or not, but its nice to see that low hanging fruits are a very important part of it.  Another thing I’ve noticed is that low hanging fruits in our project seem to be the precursors for a lot of the high risk, high energy, high payout tasks.  So putting up the software requirement spec template and the vision statement template are the low hanging fruits, but they are important enough that without that initial step things would at the least be slowed down.