Fabulous IT

Lolcats (or dogs in this case) make everything better. Refactoring is a method for improving software by applying various techniques. Adding a lolcat is easy, refactoring requires practice and experience. As one might reasonably imagine, it is hard to write good code unless one knows how to code well. Refactoring integrates into the learning experience, it helps the programmer learn as they go. Writing good code also requires proper motivation. Some of the best programmers start projects with bad code, but there is a reason.

Counter to traditional thinking, it is often not prudent to spend too much time planning a program up-front. There is a high level of risk involved in not understanding the requirements for a project, but there is also a high level of risk in not being prepared to adjust to changing requirements. In real world scenarios time is often equated with a cost, and this creates a need to balance time invested towards progress and time conserved for adapting to change.

The idea of refactoring is simple, assume everything can be made perfect the first time. Make it "good enough" knowing that there is time set aside later for making it "better". Better can mean a wide variety of things from cleaner code, to optimized performance, and even adapting to changing or better understood requirements. Refactoring is a well established and accepted part of agile software development, so much so that there are variations on the practice.

One variation proposed by Pugh in Prefactoring is to apply many of the same practices as refactoring to the initial planning process. The trade off is higher planning time, but potentially less need to refactor. An important fact to keep in mind is that prefatoring still relies heavily on expertise to yield successful results.

Refactoring is especially effective on development teams. As Cockburn proposes in Agile Software Development there is a wide spectrum of expertise among individuals, and the level of expertise a person has affects their perception of the software development process. Careful awareness of these differences can create great opportunities for personal growth and project success at all three levels: personal, organizational, and technical.

Refactoring can also help the solo developer, but small and one man projects are situations where Pugh's idea of Prefactoring may be more effective. In the software industry, large teams are not uncommon, but in the academic IT environment small teams are the norm. It can be challenging to apply agile software development  methods to academic IT projects. Most agile information resources are written for, and based on the experience of larger project teams. Fortunately just as early adopters of agile saw that the need for projects to remain flexible was critical to success, those that followed saw that a one-size-fits-all solutions lack flexibility. Many recent publications and approaches have tackled the issue of "project configuration", giving developers guidance in selecting which methods will work best for their team.

Through the next few articles, this un-refactored code written in PHP will be used as an example for various refactoring practices. It is used to pull information from an RDF news feed and publish it to an online communication tool called Twitter.