Guest speaker

I found Jeff Van Dyke's talk today in class to be really informative. All semester we have been discussing principles and practices for how to "do" software engineering. Almost all approaches have their pros and cons but it was very interesting to see these principles and conventions put to use in a successful business. I was particularly interested in the use of "small" commits and in the use of the "fudge factor" to encourage developers to become more accurate in their work estimates.

First, regarding commits, I have found that small commits can be quite tricky to do and still maintain a code base that is completely functional and runnable. Depending on the task, it can be difficult to break it up into tasks that you can code in a relatively short period of time (say an hour or two) while still maintaining a fully functional code base. I understand the importance of being able to do small commits, especially, as Jeff mentioned, when you need to "roll-back" the code in order to determine when and where a particular bug or problem was introduced. However, I think it takes a lot of skill and practice to plan out your commits so that you do them frequently enough that they are small, but at the same time, they keep the code base buildable and runnable. I personally have been trying to force myself to do more frequent commits when I am working on a feature or bug, but sometimes I get so caught up in coding that I forget or else I can't seem to figure out a good way to break up the feature's parts so that I commit every few hours. It is definitely something I need to practice more.

Second, the idea of allowing developers to use a "fudge factor" during work estimates is an interesting concept. I was familiar with the practice of adding a certain amount of "padding" to a work estimate, as I have done that at my work as well. I am usually optimistic about how long something will take me so I force myself to add some extra time for the unforeseen problems that inevitably occur. I have been also trying to do this for the Demigod project as well, but this has been harder than I expected because I also have to keep in mind the fact that I am still not an expert in all the tools we have been using so I still have a little bit of a learning curve when trying to do new things with the code. However, using a fudge factor for my estimates would be a good way for me to determine if I am consistently over- or under-estimating how long it takes me to complete a certain task or feature. It would also force me to keep track of my past estimates so I can use those to determine how I am doing.