Hacker News Reader

Comment by eclark | Hacker News Reader

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.

View on HN

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.

> 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?

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.

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.

Very good point. I stand corrected.

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

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.

> 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.

> 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.

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.

Maybe you are being down voted by fans of the former-planet Pluto? Sensitive bunch, those guys.

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.

Reply on news.ycombinator.com