tdd

The most compelling reason for TDD

I practice TDD. There are a lot of reasons for this. Many of my reasons didn’t even become clear to me until after I had been doing TDD for awhile. Most people will tell you the same. It seems there are untold benefits that you have to experience for yourself. Just try it and see. If you are told about the benefits up-front, you will simply never experience for yourself how dramatic of an effect TDD can have.

But there is one reason to do TDD that I find more compelling than any other, and that reason still makes sense even if you only think about it.

The reason is simply that . . .

northern_lights_iss_20131009

Why software teams that are on time and on budget probably suck

Many people in the software industry are bad at their job. Probably more than in other industries. Plenty of data shows the abysmal results of software projects, but you can simply ask your nearest software professional for plenty of horror stories. I have more than ten years of experience “on the inside” of the software industry and I have found bad software teams everywhere I look.

Bad managers have a disproportionately high impact on software because bad managers build bad teams, but the individuals on the teams themselves—even the good ones—are, more often than not, complicit in and even the cause of bad software. But what is most surprising is that bad teams are almost always rewarded for their incompetence. They “meet deadlines” so they are considered to have delivered “results.”

And what’s wrong with delivering results? . . .

Non-functional requirements are important yet often forgotten

abolla_18076_sm

Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.

Just to set some context, I would describe “functional requirements” as software requirements that . . .

More Peopleware quotes

“The business we’re in is more sociological than technological, more dependent on workers’ abilities to communicate with each other than their abilities to communicate with machines.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“The purpose of a team is not goal attainment but goal alignment.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“Whether you call it a “team” or an “ensemble” or a “harmonious work group” is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“So far, the results confirm the folklore: Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them. When the two did the estimating together, the results tended to fall in between.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

peopleware

Open Office Plans – Excerpt from Peopleware

From PeopleWare: Productive Projects and Teams, Third Edition, by Tom DeMarco & Timothy Lister, © 2013 Addison-Wesley.


The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.

The hypothesis that qualities of the workplace may have a strong correlation to developer effectiveness is an easy one to test. All you have to do is devise a set of fixed benchmark tasks, similar to those that developers do in their normal work, and observe how well they perform each of these tasks in different environments. The Coding War Games were designed with exactly that purpose in mind.

In order to gather some data on the workplace, we had each war game participant (prior to the exercise) fill out a questionnaire about the physical quarters in which the work was to be performed. We asked for some objective data measurements of the dedicated space provided and the height of partitions, (for example) and for answers to some subjective questions like “Does your workplace make you feel appreciated?” and “Is your workplace acceptably quiet?” Then we correlated their answers to their performance in the exercise.

An easy way to spot the trend is to look at the workplace characteristics of people who did well in the exercise (based on a composite performance parameter) against those of participants who didn’t do so well. We chose to compare the top quarter of finishers with the bottom quarter. Average performance of those in the top quarter was 2.6 times better than that of those in the bottom quarter. The environmental correlations are summarized in Table 8-1.

The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The top performers’ space is quieter, more private, better protected from interruption, and there is more of it.

Table 8-1. Environments of the Best and Worst Performers in the Coding War Games
Environmental Factor Those Who Performed in 1st Quartile Those Who Performed in 4th Quartile
1. How much dedicated work space do you have? 78 sq. ft. 46 sq. ft.
2. Is it acceptably quiet? 57% yes 29% yes
3. Is it acceptably private? 62% yes 19% yes
4. Can you silence your phone? 52% yes 10% yes
5. Can you divert your calls? 76% yes 19% yes
6. Do people often interrupt you needlessly? 38% yes 76% yes