
On Programming Deadlines - craigkerstiens
http://rdegges.com/on-programming-deadlines
======
vrde
I strongly agree with all the 5 rules Randall pointed out. But, IMHO, the very
first step to really understand those rules is to dramatically fail on every
one. [this is my first comment on HN! :)]

------
raganwald
I think the article is fine as written, but in the interests of expanding on
its ideas, I submit that writing tests first is a design technique and
maintaining substantial test coverage is a regression-proofing technique. Both
also serve as documentation.

I mention this, because these three objectives--design, regression-proofing,
and documentation--can be achieved in various other ways besides writing tests
first, and it can be helpful to separate them in your mind even if you choose
to practice TDD with great discipline.

~~~
stonemetal
I always hear that TDD is good for documentation, but most of my unit tests
cover odd corner cases, weird error conditions and the like. It certainly
isn't a show of what to do. What do you do with your unit tests that make them
high quality documentation?

~~~
mononcqc
That's often true of tests that were only used to check the validity of code,
not its design.

In many uses of TDD, you will use somewhat broader specifications to test
things. "The login system accepts any user with a valid name by returning '1'
and returns '0' if the password isn't the right one". You can have a test to
verify that without using special corner cases, and a test such as this one
will likely look like any other normal use of your library or function.

If you develop all your requirements using TDD, then both the corner cases and
the standard cases should be sitting in the test suite. The standard cases can
act as documentation and a design tool while corner cases are really more
there to insure things work absolutely right.

------
gurraman
Setting up deployment routines early is a seriously great tip. It took me
years to realize that, and to start doing it.

------
treefrog
I read so many meta-programming articles that try to make a science out of
"getting shit done."

While there are techniques that aide in the process, your time is better spent
trying to get the aforementioned shit done.

------
agentultra
Lots of good points. If you liked what you heard in this post, I recommend
reading _The Clean Coder_. Uncle Bob has a lot of great little anecdotes when
it comes to dealing with non-technical stake holders and deadlines.

------
jwallaceparker
The part of the story I don't like is where the boy gave up looking for the
dog after an hour.

~~~
JoachimSchipper
Did you comment on the wrong article?

------
arctangent
I don't have time to implement TDD.

~~~
alttag
The counter argument is, of course, that you don't have time _not_ to.

Many programmers who begin TDD have the same concern as you. Many of them find
that over time they're more productive over the long haul with TDD. It takes a
little while to arrive at that realization.

~~~
illumen
Depends on the project.

~~~
vrde
Please be specific.

In my experience, even if you are building a quick'n'dirty prototype, you'll
always need to fire up a terminal or run the GUI to interact/play with the
prototype you are building, to see if it "works".

In this case you may apply a --this is my very own definition-- "lightweight
TDD approach" just to automate all the procedures that you normally do to test
your prototype. Moreover, since you are writing a test for something that does
not exist, it may help you defining better what you want from your
experimental code, because you are using your prototype _before_ it even
exists :)

~~~
MortenK
TDD takes longer. Studies conducted at Microsoft and HP (or possibly IBM),
found that development time with TDD was 10-30% longer. That's probably
minimum, and in high degree determined by the TDD experience level of the team
members.

The massive upside is that there is _much_ less defects in the end product
(think it was 50-80% in the study, but can't recall exactly).

Depending on the project, the extra time needed, might or might not be worth
it.

Take a somewhat complex web app, that is used for a marketing campaign. It has
a life time of only 2 months. In this case it does not make sense to use TDD,
as the lower defect rate and "future-proofing" qualities, might very well not
be worth an increased budget.

~~~
alttag
Yes. My experience with TDD is that it did save time, but not necessarily in
initial development. The long-term effect of fewer defects combined with the
capability for a higher release velocity is a net savings.

As a counter example, I'm working with a company that uses TDD for their
current development, but employees work on a platform with little test
coverage. As a consequence of lacking unit tests, they're only able to release
a few versions each year because their manual testing burden is so high
(estimated by one manager as about half of the cost of a release). They've
found that TDD for their new features doesn't escalate the QA cost as
significantly as not doing it. Bottom line: it's a little more time up front,
but they've found it to be a long-term gain.

