In some 350 days of development on the same application, I developed an attitude extremist and dogmatic about maintaining the quality software. I have to irritate more than one team in (sorry) . In this post I attempt to justify this attitude. (The developer extremist was unveiled in the ticket GOOD CODE ).
THE STORY
Have you ever noticed that when the landfill is closed, there is sometimes an individual who empties his trash in front of the gate? (See photo ) Have you also noticed that once a first "vandal" got the ball rolling, others follow his example.
"After all, the entry is already polluted, so it's not some more trash that will change something ... "
Sometimes, others continue this degradation even though the landfill was reopened!
What is notable in this behavior is that the first to degrade the entrance of the landfill commits the act as "difficult" . It degrades a clean place. By cons, it is much easier for subsequent follow this example by continuing to degrade the place .
It is also notable that if the staff of the discharge was immediately cleaned debris from the first vandal the following probably would not dare dump their garbage outside the door .
back on topic
This syndrome
translates the code of a software application. If a leading developer initiates the degradation of the quality of code, for example, does not test its amendment, leaving compilation warnings or not meeting the standards of the application, while others will continue to degrade the application .
"After all, why test my change while 20% of lines of instructions are not covered? My untested code will drown in the mass and go unnoticed ... "
"After all, why spend time correcting my 2 compilation warnings when it detects the build already 23? "
more than 350 days of developing the same software, and 25 contributors, we noted that if the quality starts to deteriorate, so the runaway phenomenon . It becomes very difficult and expensive the stem and reverse the . We can even conduct an autopsy this phenomenon by observing our historical curve of non-quality (see preceding note dedicated to this practice ) . Moreover, we use the same curve to detect the onset of the problem and initiate corrective actions. There
Another reason why we must maintain the proper mapping. Our full build publish a list of non-quality detected. The list is more important and more difficult it is for a developer to find the problems with his work. Gradually, the developer will get tired to look for flaws that relate directly to the middle pages of defects.
By cons, if the list of faults detected is very low, then each developer will end up immediately and very clearly his lack of quality. It will be so visible that other teammates will also find. So, naturally, each developer will avoid being pinpointed as a contributor to non-quality by correcting its flaws at the earliest.
PREVENTION IS BETTER THAN CURE
This seems very natural. If it is not strictly content, the application will gradually "rot". It will be increasingly difficult to change the software. Worse, the heap of small faults without consequence dangerous bugs will hide.
To overcome this problem, I think it is important to develop an attitude about the extreme degradation of the application. This is especially true if the application is large, if the project is long, if the number of contributors is large or if the application is critical (our project met all these criteria at a time) . It makes sense to strive to remove all defects at the earliest to leave a clean code that nobody wants deteriorate.
FURTHER
In other contexts, this phenomenon and the right attitude to contain it are known as Fixing Broken Windows . This same phenomenon has been transposed to the development of software by the Pragmatic Programmers in their article Entropy Software in maintenance Do not Live With Broken Windows and in their excellent book The Pragmatic Programmer .
Good reading!
0 comments:
Post a Comment