The part of the story I don't like is where the boy gave up looking for the dog after an hour.
That was my favourite part!
On Programming Deadlines
11–20 of 24 posts
Re: On Programming Deadlines
#12Earlier 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.
I'm curious, are you against unit testing in some scenarios or just TDD? I'm sure we can think up some conditions where the cost won't be returned. Is that all you mean?
Re: On Programming Deadlines
#13Earlier quoted context omitted.
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 wr…
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.
Re: On Programming Deadlines
#14I 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.
I'm prepared to concede that there may be some long-term benefits to be gained, e.g. in reducing the amount of maintenance work carried out over the lifetime of a project.
However, writing detailed tests up front would completely destroy my "flow" when implementing features in a web application. It would certainly take me more time because there is going to be a large increase in the amount of code to write.
I simply don't have the time available to do this. I get a few weeks to knock out an application and then I'm on to the next thing!
Re: On Programming Deadlines
#15Lots 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.
Re: On Programming Deadlines
#16I 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.
Re: On Programming Deadlines
#17Earlier quoted context omitted.
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 wr…
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, m…
Re: On Programming Deadlines
#18Earlier quoted context omitted.
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 wr…
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, m…
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.
Re: On Programming Deadlines
#19I don't have time to implement TDD.
TDD is particularly valuable (I'd even say unavoidable) when writing modules, libraries and so on. It's extremely helpful on some tough program parts that aren't enough defined in behaviour by the spec. Writing tests first in these case will avoid you countless traps, particularly in "the other 90%" as mentioned in the Cargill's law:
"The first 90 percent of the code accounts for the first
90 percent of the development time. The remaining 10 percent
of the code accounts for the other 90 percent of the
development time."
—Tom Cargill, Bell LabsRe: On Programming Deadlines
#20I 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.