'The minute I make a change, everyone gets it' is, I hope, a fallacy in the world of on-line software. It omits a major stage between 'making a change' and 'everyone getting it'. The following is a brief outline on how I fixed a bug in one of our in-house systems. This system is not used by customers, is very important for us and the bug was annoying. Our project estimation software allows us to nest, or group, requirements together. We may, for example, have a requirement 'Screens' with sub-requirements of 'Client Search', 'Client Maintenance' and 'Client Maintenance'. Full details of each requirement are available on-screen. Along with the ability to enter the estimated number of hours for each requirement we also show the estimated cost (hours x rate) for the requirement and all its sub-requirements. In our example 'Screens' will show the estimates for itself and its three sub-requirements. A recent addition to print each requirement was supposed to duplicate the on-screen view but in a better formatted, .pdf format. I just noticed that the costs shown were for the sub-requirements but excluded the selected requirement. On comparing the code for the screen view and the report code, I noticed a couple of things: 1) that the report summed sub-requirements but did not add in the value for the selected requirement, and 2) the same code was in two places (rarely a good idea). So, I created a new, shared, function from the correct, working code. I commented out (temporarily removed) the code from the on-screen program and the report program and replaced it with a call to the 'new' function. I then tested the new on-screen program to ensure that the calculated values were correct for the bottom-level requirements and for each of their 'parents', manually calculating values and comparing them with the screen. I then did exactly the same for the printed report, comparing the report with the on-screen values and the calculations. Once content with testing, I removed the commented out code - I was using the new function so this code was now surplus. Now, I had changed two programs, even if only to remove unused code. Because it's so easy to press 'delete', I retested to ensure that I only removed the code that should be removed and no more. Now that I am happy with my local testing, I released it to Google App Engine's (tm) production system. The way we work with Google App Engine is that each release receives a new version number. This means that, while in production, the new release is not the 'current version' for use by the public. Once in the production environment, I repeated all the above tests on live project data that I am familiar with to confirm the results. Finding no errors in the system I had just released, I made the 'new' version the 'current' one. Finally, the new system is live and we have the 'old' on still in place just in case we need it. Had I found any further errors, I would have repeated this entire process. I hope this helps you understand a little of the process we follow to fix bugs and add features to our systems. This should also show you that even little changes require work to ensure that other changes are not made 'accidentally'. Please get in touch if there is anything Freeman Software can do to help your business succeed.