On Programming Deadlines
rdegges.com
On Programming Deadlines
1–10 of 24 posts
Re: On Programming Deadlines
#2The part of the story I don't like is where the boy gave up looking for the dog after an hour.
Re: On Programming Deadlines
#3Setting up deployment routines early is a seriously great tip. It took me years to realize that, and to start doing it.
Re: On Programming Deadlines
#4The part of the story I don't like is where the boy gave up looking for the dog after an hour.
uhh.. what now?
Re: On Programming Deadlines
#5The part of the story I don't like is where the boy gave up looking for the dog after an hour.
Did you comment on the wrong article?
Re: On Programming Deadlines
#6I don't have time to implement TDD.
Re: On Programming Deadlines
#7I 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! :)]
Re: On Programming Deadlines
#8I don't have time to implement TDD.
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.
Re: On Programming Deadlines
#9I don't have time to implement TDD.
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.
Depends on the project.
Re: On Programming Deadlines
#10Earlier quoted context omitted.
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.
Depends on the project.
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 :)