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