The Benefits of Small Changes

for RuBoard

Changing code in small chunks has a number of intrinsic benefits. Chief among them is that making small changes reduces the risk of introducing bugs. Bugs are the result of human error, and the smaller the change, the less chance there is for something to get past you. By reducing the chances that an initiative (however small) you've undertaken in your code will fail, you increase the chances that the project will succeed overall. A project is nothing more than a number of related smaller initiatives tied together by a common goal. As Kent Beck says in his book Extreme Programming Explained , lowering the risk of project failure by shortening the release cycle (and thereby reducing the number of changes made in a particular release) helps ensure both the survival and the success of the project. [2]

[2] Beck, Kent. Extreme Programming Explained: Embrace Change . Reading, MA: Addison- Wesley, 2000. Page 4.

This admonition holds regardless of whether you're cleaning up existing code or adding new features. When adding new features, adding them one at a time ensures that each feature works before adding the next (because you test each feature before moving on), and it also introduces flexibility into the development process. If your user base or management hierarchy decides that Feature X is more important than Feature D, this reshuffling of the priorities shouldn't derail the project if you're still completing Feature C. In the hectic world that is software development today, you must be able to adapt quickly to what your users and management want, and working on small pieces of code at a time helps you do that.

Like a sculpture, the ultimate shape a software creation takes is not entirely knowable in advance. It evolves as the process continues to fruition. Software development consists of a series of tradeoffs between the desirable and the possible, with what is perceived as desirable and what is perceived as possible evolving during the course of the project.

Michelangelo liked to say that his sculptures were present in the quarry stones before human hands ever touched them. His job, he felt, was to find these creations among the fissures and imperfections of the source stones and expose them to the light of day. He would often spend weeks or months studying a stone to determine its possibilities before ever striking it with a chisel. Although his work was immensely creative, a certain amount of forethought and planning went into it. He studied and planned to innovate. The software craftsman does the same thing: He extracts , from the raw materials handed him, software sculptures waiting to be uncovered, creations derived directly from their source materials, imperfections and all. These "imperfections" may consist of changing user requirements, unpredictable resources, and premature assumptions and conclusions regarding what's do-able and what isn'tthings that seem to change with each passing day. The craftsman's job is to find a creation that pleases his benefactors in spite ofand, indeed, because ofthese unpredictable elements.

for RuBoard


The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
ISBN: 201700468
EAN: N/A
Year: 2005
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net