Milena Velba In Leapord

RATE (IN) SUSTAINABLE

On his blog on the mailing list XP and France FrenchSUG , David Brocard restarted the discussion on the implementation of agile principle of sustainable pace.

SUSTAINABLE MOMENTUM

"Agile processes promote sustainable development pace. Sponsors, developers and users should be able to maintain a constant pace indefinitely." (Agile Manifesto )

This principle is very laudable

• He favors long-term goals on short-term goals.
• It provides continuous flow and constant value creation that maintains product quality, ensure progress and improves the predictability of development.
• It establishes a rhythm to establish the systematic problem-solving and continuous improvement .
• He recalled that the development is carried out by men and must comply pace of work - in their interest in the project and clients.
• It allows enchainer projects, one after the other, because developers are still available (in good condition ...) .

THE PROBLEM

• Looking back over several years of project do sustainable pace was applied ?
• Is it compatible the implementation of other principles of Agile Manifesto?
• A t we at least won a more sustainable pace before, when we use methods more theoretical and (falsely) predictive? After 150
• open days of development on a project, I wrote that we were past the iteration sprint on our project, losing the sustainable pace (see ticket ) . What about after 350 days of development on that project?

IS THE HARDER TO COME

Before the adoption of approaches like agile projects on the pace was sustainable along the V down. To take an intermediate step (specification, design, coding) it almost enough to decree that the activity was completed. Specifically, it was impossible to objectively prove the contrary, since no evidence was relevant. Also, we knew not too daring to say that the work would be resumed and completed in phases upbound of V.

Then the pace became much more uncomfortable during the ascent of V. The integration code turned to nightmare and hours accumulated to develop (and rewrite) this software. This phase was the culmination of fatigue and stress on the project. The worst was that the duration of this phase was unpredictable ...

All this to say that before the introduction of type methods agile, the pace of projects was already unbearable, but mainly on the ascending branch of the V.

IS HARD ALL THE TIME

With practice lifecycle iterative and incremental short , stress and hours of work have not disappeared. They were smoothed fairly evenly along the development (it remains at the peak of iterations prior to a formal delivery) . Also, the stress and pressure of work appear very early in development.

This change is due to the nature of the cycle iterative and incremental installing a short rhythm during which all development activities are conducted, raising issues early and often.

With reviews and demonstrations iteration increment, the stress of delivery becomes periodic. The availability early and continuous velocity (and other indicators) can lead to a race to productivity, fueled by expectations of ever more ambitious managers.

Thus, agile methods do not seem to generate a more sustainable pace and more untenable. By cons, they smooth early and throughout the project stress which peaked before the end (theoretical) development.

Note that the technique of Heijunka in this specific research Lean smoothing the workload and stress.

NO PIC OR BREAK

course, with a nimble style approach, there are more large peaks of work and stress. By cons, there is also no longer break . With more theoretical approaches, the breaks did not exist formally, but it was possible to calm the pace on the descent of the V. By cons, with a daily- stand-up-meeting with the burndown chart updated daily, with a build published and with acceptance testing automated measuring progress, it becomes very difficult to calm the pace without it being noticeable. And this comes together iteration after iteration. We're at 18 iterations of 20 days on the same project - and use it!

To calm things down, we tried to take a day without functional increment iteration between the journal and planning for the next. On the one hand, it went wrong with the management, on the other hand it does absolutely no overtaking sprint from 20 days before another sprint of 20 days.

THE RACE TO THE VELOCITY

To maintain a sustainable pace, it takes aim at a lower velocity in iteration planning. This seems obvious. It is certainly applicable in the best of worlds, in the enlightened companies, Google and among Bears. Unfortunately, this is not possible with managers who think that developers use the time allocated to them ( Parkinson's Law ) . This management model is applied. By extension, it is untenable to set targets to be "on" that developers whoop. Change this pattern of thought can be a cultural revolution for some organizations.

STRESSFUL TRANSPARENCY

At the rate plus the stress of transparency . It takes courage to display its productivity curve and the curve of non- quality. It takes courage to post a the umière which turns red when the build is broken . It takes courage to show his problems. Provide indicators that may also be give the stick to get beaten . Being transparent is also welcome criticism: "When we lost his keys at night, they are looking under the lamppost " (Francis Brown) .

NEW SYMPTOMS

With practice approaches like agile, we find that the teams become more cohesive. With stress, they develop a rich folklore team . For example, a sociologist our exciting team so it has developed practices such as the "Gizmo" , "Perfect" , "jumping off the top rope" , "the J'off" and many others.

rich folklore of this team is much less attractive if interpreted as being collective mechanisms of protection against suffering work. Unfortunately, this is a very common operation studied by psychodynamic . With the close-knit teams, we went from individual mechanisms to collective protection.

The fact that a team is united and developed a rich folklore can be a sign of distress felt by the work crew. This can be a symptom of unsustainable rate. The worst is when these symptoms are misinterpreted and are charged to the team as bad behavior. This amounts to suppress the symptom of Maletras.

WHATEVER THE METHOD

Whatever the method, working in project mode is challenging. As long as there are milestones, they are ambitious (for economic reasons) and it would hurt keep them. This is not unique to software development. In creative, advertisers, journalists, writers and architects, this is called the periods cart ( intense period of work time to complete an order, a task contract ) .

BUT

The type processes have the characteristic of agile smooth the workload over time and go very early rhythm. This rhythm is no peak or break . Add to this the stress of transparency . Clearly, it takes courage to practice a kind of agile approach.

variable adjustment remains the cursor velocity. After that it played with the corporate culture and management style. The pace is unsustainable in the gene pool of agile methods in use but that the sponsors, developers and users can (very easily) do. These steps are
devilishly effective and motivating but they can not of course solve all .

First Audition Streaming

SYNDROME OF THE DISCHARGE

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!

Cosmetics Qualifications

PUBLIC GOOD CODE ...

In order, a good code

1. passes its tests successfully;
2. can be misused;
3. contains no redundancy;
4. clearly expresses the intention;
5. is as short as possible.

Paraphrase ...
A little close, points 1 , 3 , 4 and 5 is a quote from Kent Beck , creator of the -eXtreme Programming . Practitioner programming by contract, I added point 2. (What I will not cite the work Kent Beck and Bertrand Meyer in the same post: o)

... nevertheless useful
I get to read a lot of code, binommer with many developers and teach. As part of these activities, this quote five points is very useful. I use it a lot and I quote often. I'm sure as an extreme dogmatic and stubborn ... (After all in a team, it is good to achieve a certain ratio extremist developer / developer lax)
Still there is much empirical wisdom in this quote. Among other things, the order of criteria is very important .

1. You will test
testing top the podium. A code that is not tested does not have value. Code is not guaranteed. Any line of inquiry must be covered by a test. This is true very well with the analytical tools of structural coverage.

2. You disabuse
A code that can be misused is a code undeceived. It contributes to the preventive management of defects in the application. Programming by contract is an excellent practice to key the code. Quit talking about programming by contract, it would be more accurate to say "A good guarantee its postcondition code if its precondition is guaranteed by its caller" . To learn more about this rare practice but really effective, you can read a preceding post on this topic .

3. You do not repeat yourself not
Duplication is a source of multiple faults and multiple times. It undermines the clarity of intent. Suppose that I "inherits" a untested code. Without hesitation, I prefer to spend time testing it to eliminate redundancies. (Actually, I eliminate redundancy from the tests pass: o)

4. Thou shalt be clear and explicit
The code is read much more often writes - including its author! Besides, the writer is first and foremost his own player. Much easier the lives of all these reviewers. As with the previous point, I prefer test as renaming and cut. (Same, I rename and cut out the tests pass: o)

5. Thou shalt be brief
The brevity of the code comes last because it may conflict with items 1 , 3 and 4 . In such cases, the brevity is not a priority.
To make code testable, it is often necessary to create interfaces inject dependencies to build objects . This increases code size. The test also leads to cut in small classes and there is a declarative heel to pay for this modularity.
A code without duplication can lead to an operation to create two duplicate lines. In total, counting the statement by overflow, this practice may increase the number of lines. Besides, have you noticed that the revised code examples are always longer than their original code? (see Clean Code )
To make a code more explicit, we have to standardize the level of abstraction in the code of operations. For this, we encapsulate the code level of abstraction than in a transaction. Again, we pay a fee for the statement of operations. And

test code?
This codex 5 rules apply to the code, but also tests because the tests are code. One might think that we should not test if testing is never ending. However, the practice of Test Driven Developpment end of eXtreme Programming, design integrates test test !
Indeed, when we start by writing a test that fails , then we modify the code until the test passes, we verify the accuracy of the test. Th 2-step approach is to test the test.

One more (violation of criterion 3!)
Sorry, this was the 1379th ticket to define a good code. Many books devote their pages. It's like the strings of luck / bad luck. When you read one of these tickets, one must write one to turn ...