Observations from the Backlog Management Team (aka Spencer Farley)
As the summer began to wind down, we asked that each intern team write about what they worked on, what they learned, and how this experience will affect the remainder of their formal education. In this post, Spencer Farley talks about how he – as a one-man team – spent the summer developing a backlog management application for internal use.
This summer I worked on an internal tool called Backlog Management. This tool is used for maintaining an organized repository of unscheduled development tasks. This centralized repository for ideas allows for easier collaboration between developers and project managers.
I am very proud to have a project which I can truly call my own. It was my responsibility to see the project through each stage, from architecture to deployment. Sole ownership of the project provided many insights. I now have a much more complete picture of the software development lifecycle: from starting the project to making it available to customers.
Even though I was the only developer on this project, I could not have accomplished what I did on my own. I often stumbled and was full of questions, especially as I tackled the strange new world of web based applications. Fortunately for me, I have a village to raise me. At every step I was able to benefit from the diverse expertise at Don’t Panic Labs:
- Doug helped me in the architectural phase, in finding resources along the way and always kept me thinking of what I learned
- Emily helped me in the environment setup
- Cole and Andy probably thought I was at their desks more than my own
- Kyle, Cody and Bob Whitmer provided much styling advice and assistance
- Ganz shared his wisdom in the ways of WCF
- Todd and Lori provided the domain expertise needed to shape the product and continue to give feedback on how to improve it. Not to mention they entrusted their precious ideas to a learning developer
My experience this summer has presented me with numerous takeaways that will benefit me as I continue to code. First of all, I experienced the direct results of my poorly-written code. Every bug or quirk was undeniably my responsibility. Some of the early stages of Backlog Management were unusably buggy. However, out of this I have developed better testing habits so I can be confident in the code I commit.
Secondly, the best practices book Code Complete by Steve McConnell has taught me much about the structure and qualities of good code. Perhaps the single most important practice I have taken from the book is carefully naming methods and variables. In order to give a method or variable a descriptive name, the method or variable itself must be well defined. Troubles in naming a method or variable usually means you need to refactor.
In summary, this summer has provided me with a wealth of opportunity to learn and grow. With the help many I was able to create a respectable product and grow into a better developer.
