4 ms·

All of these arguments seem like they are overly prescriptive. Individuals should use what works best for their needs. TDD may work wonders for me today on one

by eclark 12y ago

All of these arguments seem like they are overly prescriptive. Individuals should use what works best for their needs. TDD may work wonders for me today on one project, and then it could be horrible tomorrow on the next project. My co-worker might have the inverse. Stop arguing over how other people create software; Ship Code instead.

JeremyMorgan 12y ago
You said it better than me. No reason to get religious over it. When I'm the architect on a project, I do it in some cases, and other times I don't. I'm not over concerned what everyone else is doing in this regard.
GuiA 12y ago
> Individuals should use what works best for their needs Maybe rather: teams should use what works best for their needs ? EDIT: whee, downvotes. Apparently HN'ers work on teams that ship software and where a developer uses kanban, another TDD, another waterfall, another scrum, and another only commits code when the 8 planets are aligned.
- eclark 12y ago
  TDD vs Testing after is a personal choice apart from how the team set goals. That is to say you can be on a waterfall schedule and still practice TDD. As long as code shows up to code review with good tests, I don't personally care if the tests were written before or after.
- jasonlotito 12y ago
  > whee, downvotes. I'm going to take a stab at the down votes, as I could easily understand why someone might. First, consider your original comment was pedantic and offered little in the way of original insight. It would be like me replying to you and saying: "Maybe rather: teams should use hwat works best for their needs per project?" What does that really add? Basically, it added little to the conversation. Heck, your edit complaining about the down votes is longer than your comment.
- MartinCron 12y ago
  Maybe you are being down voted by fans of the former-planet Pluto? Sensitive bunch, those guys.
ericHosick 12y ago
> Stop arguing over how other people create software; Ship Code instead. Electrical engineering, mechanical engineering, architectural design and the medical profession, to name a few, have bodies of knowledge they are required to use. Is it really a good idea for software developers to say "stop arguing over how other people create software; Ship Code instead" considering we don't have any industry standard bodies of knowledge?
- lugg 12y ago
  Considering we don't have any industry standard bodies of knowledge, yes it probably is a good idea, because we don't have anyone who can lay out a definitive answer on many of our preference based arguments. i.e. these arguments will never end if there is no definitive answer, or body to pick one.
  - gary_bernhardt 12y ago
    Industry standard bodies of knowledge arise from people doing, then talking about what they did, then doing some more, then talking some more. At no point did a God of Electrical Engineering hand down tablets.
    - lugg 12y ago
      Very good point. I stand corrected.
  - Silhouette 12y ago
    There is at least one serious effort underway to collect (or perhaps, catalogue) such a body of knowledge: http://www.computer.org/portal/web/swebok http://www.computer.org/portal/web/swebok I think SWEBOK is interesting both as a demonstration of how far we have to go before we get anywhere near the standards of established engineering fields, and as a demonstration of how much we have already collectively figured out, even if most of us aren't familiar with more than a small fraction of what is out there.
ebiester 12y ago
I believe that it's a useful conversation to have -- if we are all just trying to ship code, when are we going to have the discussion of what makes code readable? What makes code reliable? What makes code quicker to deliver? Further, as a automated test advocate (whether or not it's TDD or unit or mocks or stubs or whatever flavor you like) I want to walk into projects where I don't have to deal with changing code without having a good and fast test base to minimize the potential defects. If TDD gets us to that point, I'm all for it. I don't care how you create software unless I have to use it or inherit it.

by eclark 12y ago

JeremyMorgan 12y ago

You said it better than me. No reason to get religious over it. When I'm the architect on a project, I do it in some cases, and other times I don't. I'm not over concerned what everyone else is doing in this regard.

GuiA 12y ago

> Individuals should use what works best for their needs Maybe rather: teams should use what works best for their needs ? EDIT: whee, downvotes. Apparently HN'ers work on teams that ship software and where a developer uses kanban, another TDD, another waterfall, another scrum, and another only commits code when the 8 planets are aligned.

eclark 12y ago
TDD vs Testing after is a personal choice apart from how the team set goals. That is to say you can be on a waterfall schedule and still practice TDD. As long as code shows up to code review with good tests, I don't personally care if the tests were written before or after.
jasonlotito 12y ago
> whee, downvotes. I'm going to take a stab at the down votes, as I could easily understand why someone might. First, consider your original comment was pedantic and offered little in the way of original insight. It would be like me replying to you and saying: "Maybe rather: teams should use hwat works best for their needs per project?" What does that really add? Basically, it added little to the conversation. Heck, your edit complaining about the down votes is longer than your comment.
MartinCron 12y ago
Maybe you are being down voted by fans of the former-planet Pluto? Sensitive bunch, those guys.

ericHosick 12y ago

> Stop arguing over how other people create software; Ship Code instead. Electrical engineering, mechanical engineering, architectural design and the medical profession, to name a few, have bodies of knowledge they are required to use. Is it really a good idea for software developers to say "stop arguing over how other people create software; Ship Code instead" considering we don't have any industry standard bodies of knowledge?

lugg 12y ago
Considering we don't have any industry standard bodies of knowledge, yes it probably is a good idea, because we don't have anyone who can lay out a definitive answer on many of our preference based arguments. i.e. these arguments will never end if there is no definitive answer, or body to pick one.
- gary_bernhardt 12y ago
  Industry standard bodies of knowledge arise from people doing, then talking about what they did, then doing some more, then talking some more. At no point did a God of Electrical Engineering hand down tablets.
  - lugg 12y ago
    Very good point. I stand corrected.
- Silhouette 12y ago
  There is at least one serious effort underway to collect (or perhaps, catalogue) such a body of knowledge: http://www.computer.org/portal/web/swebok http://www.computer.org/portal/web/swebok I think SWEBOK is interesting both as a demonstration of how far we have to go before we get anywhere near the standards of established engineering fields, and as a demonstration of how much we have already collectively figured out, even if most of us aren't familiar with more than a small fraction of what is out there.

ebiester 12y ago

I believe that it's a useful conversation to have -- if we are all just trying to ship code, when are we going to have the discussion of what makes code readable? What makes code reliable? What makes code quicker to deliver? Further, as a automated test advocate (whether or not it's TDD or unit or mocks or stubs or whatever flavor you like) I want to walk into projects where I don't have to deal with changing code without having a good and fast test base to minimize the potential defects. If TDD gets us to that point, I'm all for it. I don't care how you create software unless I have to use it or inherit it.