If you ever had to convince a client or a boss why Agile works, you know that it's not an easy task. Agile goes against many ideas that are considered axioms in the business world - like planning first and then keeping to that plan: "plan your work, then work your plan". If that is the case, these points from a talk by Martin Fowler and Neal Ford (ThoughtWorks) might help you.

In the Plan Driven approach, a project is successful if it goes according to plan, so in software development it depends on requirements stability, on having clear and fixed requirements. As you probably know, that is a luxury most software projects don't have, and a first approach would be to apply techniques like Change Management or Sign In Blood to contain the changes. Unfortunately that leads to unhappy clients and unusable software.

The Agile approach is to break the dependency on requirements stability and come up with a process that takes into account changes. It does that by using Adaptive Planning and Evolutionary Design.

Adaptive planning implies going through the project cycle many times, re-planning and re-adapting often.

Evolutionary design can be achieved with the help of practices like Self Testing Code, Continuous Integration, Refactoring and Simple Design.

If this made you curious, I highly recommend that you view the complete talk here:

I used the word "help" in this post ( We can’t use Test Driven Development! ) because TDD is not a silver bullet. NOTHING is. But that is not a reason not to look for improvements in the way we work.

I'm going to try to explain why I think TDD can help you in MOST of the software development projects out there.

First, mentioning something like "zero defects guarantee" when talking about TDD or testing in general is a hint in my oppinion that a lot of people see the tests as a way to FIND defects.

Myth: The Job of Testing Is to Find Defects

The job of tests, and the people that develop and runs tests, is to PREVENT defects, not to FIND them.

(Mary & Tom Poppendieck, "Implementing Lean Software Development From Concept to Cash")

Knowing that, correct me if I'm wrong with this train of thought (and see if it applies to your case, I can't think of a project where it would not apply):

1. To have or not to have tests. (By tests at this point I mean test cases, automatic or manual, covering the whole system or just a method. Tests in general).

Not having tests leaves me with the task of guessing whether my functionality really does what it is supposed to. Remember, computers do what you tell them to do, not what you want them to do. So having to tests would mean code -> compile-> mark task as done. Unfortunately it actually happens, and way too often.

But that's not the way we do it! The developer DOES check that it works!

Ah! That IS testing, so we MUST have tests then!

2. To have a test list or not.

Testing the software by randomly executing operations will not give you enough certainty that it does all it is supposed to do. The reasonable thing to do is make a list of tests that cover all the cases you can think of. Of course, the list is not cast in concrete - tests can be added or modified.

The list can be an excel or word document. Or code. Or a table on a whiteboard. Or a scribble on a piece of paper. Keep it in your memory only if you never forget anything (hello there, R2D2!).

The important thing is that it needs to specify the setup, execution and validation for each test so it can be shared among team members.

3. Define the tests before or after implementation.

Both work, but tests defined them after implementation (especially by the developer), will tend to validate what the code DOES, instead of what it is SUPPOSED to do. More, defining the tests before can help the developer contemplate cases he could have overlooked and serve him as a progress indicator (9 out of 10 tests passing is a hint that you are close to finishing).

4. Automated or manual tests.

Being able to run your tests automatically and have the feedback in seconds instead of minutes is, of course, a big plus. And, you can setup a Continuous Integration server to give you fast feedback about integration problems.

You have to take into account the time to implement them though. And testing whole applications can could imply slow operations like setting up data in databases or connecting to services. And, depending on your frontend technology, you might find that UI testing frameworks are still limited. Which brings us to the next point:

5. Big coverage or small coverage tests.

Small coverage implies cheaper tests - cheap to develop because you can mock external dependencies and check a specific flow without worrying about "downstream" effects, and cheap (fast) to run because everything is in memory - no database access or web service calls. This type of tests are usually called UNIT TESTS.

Having a good coverage of the internal workings of your components allows the bigger tests to cover the integration parts, the communication between them, validating that they play well together.

In conclusion, if the above applies to you (and if not, I welcome comments on why it doesn't): you should ALWAYS HAVE TESTS, DOCUMENT them, preferably define them BEFORE implementation, and you get a big productivity bonus if they are AUTOMATIC which is a lot cheaper if most of them are UNIT TESTS.

You just have to put some pressure on them! Set a deadline!

After all, it works for programmers, doesn't it?!?

Management is used to negotiate everything, so when the developers come with an estimation for the work to be done their first reaction is:

"2 weeks... That's ok... Now what if we put pressure on them? Tell them they have a week to get the job done."

And I can understand that... It's the job of the development managers or directors to keep things in balance and ensure the developers get the necessary time to do quality work. If not, they WILL cut corners in quality. At 10 PM they WILL choose going home over spending some more extra hours making and running tests.

What I can't understand are the people with a programming background that, as soon as they start climbing the company hierarchy, they start setting out-of-the-blue deadlines for the developers they now manage.

What über programming technique were they using in their programming days when they got unrealistic deadlines to get the job done in time AND with quality?!?

PS: Just to be clear, this article not is about deadlines in general - it is about deadlines set without taking into account the developers' estimations.

Meet Bob.

Bob is the Development Director a company that offers a Software-as-a-Service product with customizations built for clients on a project-by-project basis.

Bob was there from the beginning. Actually he is the only one remaining from the handful of programmers that started the software. That fact alone pushed him into the position he is in today, managing about 50 programmers. He's standing among the other directors is very important to him - he wants to be seen as the guy who gets the job done, no matter the absurd deadlines. Of course "done" is relative, if you don't care about quality - everything that happens after "delivery" is the client's problem.

Bob's philosophy is simple: "If it worked until now, we MUST keep doing things the same way!". It doesn't matter that things that barely worked with 5 programmers are literally ripping the code apart now. Although his background could be defined as using technology to automate activities, he is surprisingly blind to the opportunities of improving his team using software.

So they keep using manual source control by writing the changed files and lines in notebooks and then manually merging them.

So they keep having just one development database instance where the developers make their changes and run their tests at the same time. Of course, because nobody removes their unused stuff on one side and changes being made directly in production, only about 30% of its schema is equal to the production database.

Apart from his philosophy, Bob has his excuses ready whenever somebody tries to convince him to improve the way development is done:

"We have these projects in progress and they must be delivered on time".

Makes sense. The problem is that this is forever true. When new projects arrive, Bob conveniently forgets about the time required for improvements and keeps doing the same old again.

Why does Bob do that?

"Because we have to keep the pace of deliveries".

Actually Bob "pace" is too slow. Extreme case: if Bob stops everything for a month in order to implement a practice that would give him an 10% improvement in delivery times, he would recover his investment in one year. But he lost his long-term vision. Imagine that he had done that 2 years ago. Now he would have extra income equivalent to one month's work. Let me rephrase that: Because he didn't act in time the company is losing thousands or millions at this moment.

But it's not Bob's fault:

"The salespeople make commitments to the clients and we have to deliver, even if there is not enough time".

Salespeople will always try to do that. Whatever it takes to make the sale, even if it means cutting the delivery time in half. It is the development director's job to maintain the balance. And see the point above. He could deliver faster.

If Bob HAS to act,

"We'll do it gradually. Baby steps. This will take a loooong time".

What this means is "We'll pretend we're doing it so you'll stop bothering us". He's not committed to improving the way work is done. It results in one or a few "pilot" teams experimenting other ways of doing stuff, without adequate measurements in place to check for success. Management support lacking, the teams rapidly lose their way and revert to the old practices or they are told to do it because there are no "visible" improvements.

And then, he can always use this:

"We hired cheap people and they are not capable of learning new practices".

So you looked for inexperienced people, that's OK. You didn't look for the dumbest, did you?!? Even if they are dumb, they learned the current practices - why wouldn't they be able to learn new ones? Unless... you DO TRAIN your employees, don't you?

And what if change comes from "below"? Bob has a zero-tolerance policy for programmers that do not obey his "religion".

The result: the smart people look for other opportunities while the company loses its competitive edge. Of course it's not Bob's fault... seeing farther than tomorrow's deadline was never his job, was it?

PS:

There is a happy face in the post, so nobody should get annoyed. If, despite the happy face, you still are annoyed by this post, you probably ARE Bob.