Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Start-Up Trap

blog.8thlight.com

Post reply on HN
Print view View original

81–90 of 145 posts

Re: The Start-Up Trap

#81

Post by hartator »

hack_edu wrote: post #18
hartator wrote: post #5

Earlier quoted context omitted.

I agree. Prototype are not very well defined and prone to rapid changes. Besides that, when you have an app that interact a lot with third parties APIs, it's almost impossible to make useful tests. One guy working with us has basically mocked the whole world wide web to allow him to do TDD, sometimes TDD is just plain stupid.

I don't understand your point. If your third-party APIs are volatile and out of your control, causing a liability in maintaing tests... wouldn't that cause an even bigger liability in your application code? Such volatility is even more dangerous to your application. This is why we have integration tests. This is classic case of why you need tests and integration policy . When your APIs change or break, the tests brea…

I agree in parts. In real life, you can't always do integration tests against third parties for various reasons, the main one is that some websites/apps don't like to be taken as a sandbox to try out every CRUD operations we can have in mind. If you isolate too much, your code will be running against only itself and won't be again that useful. The way to assure software quality for our case is to carefully check on logs from data from real users, pretty regular actually. Not as sexy as TTD, but customers appreciate you take care about their real account or not another Foo Bar foo@bar.com profile.

Re: The Start-Up Trap

#82

Post by sanderjd »

pifflesnort wrote: post #79
MattRogish wrote: post #23

(tl;dr: it depends) It's a hallmark of "experienced" non-dogmatic product people (UI/UX/Dev) that can use their intuition to know what are the happy paths that they need to test, what interfaces are likely to not change (e.g. a user is probabilistically always going to be a member of an organization, so unit tests around that are likely not waste), and what level of quality to introduce for a given feature relative t…

> After you prove this feature is a "thing" you want to keep around (and you've nailed down the interface), then it's a perfect time to re-write it with a much higher degree of test coverage. I find that tests help me write things that are complete and "nailed down" the very first time.

You must have read that with a different definition of "interface" than I did. Under my reading of "user interface", I don't see any way that a developer writing tests has anything to do with how nailed down it is. You need user feedback for that.

Re: The Start-Up Trap

#83

Post by Mahn »

I'm not sure if the author has any idea what is it like to bootstrap a web product and watch the money go down the drain day after day, with zero income to compensate, and with the certainty that you won't make it for another 6 months if the product is not out and making revenue. I'll deal with the technical debt later, thanks. I'm pretty sure Facebook and Google didn't do anything remotely close to TDD when they first shipped, and yet they survived.

Re: The Start-Up Trap

#84

Post by [deleted] »

sanderjd wrote: post #82
pifflesnort wrote: post #79

Earlier quoted context omitted.

> After you prove this feature is a "thing" you want to keep around (and you've nailed down the interface), then it's a perfect time to re-write it with a much higher degree of test coverage. I find that tests help me write things that are complete and "nailed down" the very first time.

You must have read that with a different definition of "interface" than I did. Under my reading of "user interface", I don't see any way that a developer writing tests has anything to do with how nailed down it is. You need user feedback for that.

[deleted]

Re: The Start-Up Trap

#85

Post by icedchai »

TDD is often a waste of time. I worked at some place that had taken the TDD philosophy to the extreme: every getter and setter had a test.

On the opposite side of the spectrum, I worked on software that processed millions of dollars in daily transactions and there were maybe 5 "tests" in the whole system. This was about 500,000 lines of C and C++ code in the early 2000's.

My personal philosophy is to write unit tests where I think it's important, not test everything.

Re: The Start-Up Trap

#86

Post by agilord »

petenixey wrote: post #39

Man, I've been back and forth on tests from one extreme to the other. I have to say that I do agree with this but with one caveat - Test Driven Development is a bit miserable. Test "Driven" Development is a real invitation to write too many tests. A small, good set of tests gives you freedom to work fast, to refactor and to have multiple developers pushing simultaneously. Not having them really isn't sustainable past…

I'd like to emphasize this approach: "a nice self-annealing approach to get into testing is to only write tests for something that has failed."

It is great for old-timer enterprises without any test, and balances the time pressures of startups. However, you need to write those test not only for prod failures, but also if that something failed in your dev environment.

Re: The Start-Up Trap

#87

Post by [deleted] »

tmoertel wrote: post #40
jmduke wrote: post #15

I like to talk about TDD using a finance analogy. One of the first concepts you learn in introductory finance is that, in a mature market (ie the stock market -- basically something with a bunch of people and a bunch of information) you have to be compensated for risk . This is why a riskier stock -- like tech stocks or penny stocks -- can boast incredible amounts of risk but generally will give you higher returns ov…

> By definition, going through TDD is going to be a safe route, ... Why is TDD safe? Most TDD advocates seem to be blind to the fact that testing is a terrible way to prove many important properties about software systems, security properties for example. If you're betting your ever-so-scarce programming resources on TDD, you're probably paying too much, getting a lower return than you could be getting, and leaving s…

[deleted]

Re: The Start-Up Trap

#88

Post by derefr »

j_baker wrote: post #45
thetrumanshow wrote: post #19

Earlier quoted context omitted.

Had I opened with "Interesting article, but tangentially..." then we'd still disagree, but maybe we could have avoided the straw-man ding. :)

You're right. Then we'd have a passive-aggressive ding. The only thing you would have to add to make it perfect would be "...but I'd never claim the author is trying to do that."

I wouldn't even call it passive-aggressive; it's soapboxing, plain and simple.

> This article is about X. But I don't care what the article says about X. I have something to say about X, and by God, I'm going to say it.

--But I don't know that this is a particularly problematic thing to be happening in a threaded comment system, since people can get sidetracked by "soapbox issues" in a subthread while letting the "parent conversation" continue around them. It's just kind of confusing for people who treat this place like a linear-chronological message-board that discusses one topic at a time.

Re: The Start-Up Trap

#89

Post by michaelochurch »

This "trap" is Deadline Culture and it doesn't pertain only to code quality, but to other matters like product direction and personnel decisions, which are made quickly and often badly. It's sloppy and destructive. Companies with Deadline Culture often make it easy for a total asshole to gain power just by citing existential risks that either do not exist or are of extremely minor importance. Deadline Culture companies are obsessed with competitors, even though it's their own internal corrosion that does them in.

Sometimes, having deadlines is unavoidable. They might be set externally and exist for regulatory reasons. Deadline Culture is when the company starts encouraging the formation of unreasonable deadlines that triumph over professional integrity and intellectual honesty.

VC-istan seems to encourage it with the whole "if we get bored with you, we'll fund your competitors" arrangement.

Deadline Culture is, however, great for the true fascist. Fascists love (real or imaginary) existential threats, especially vague ones they can continually adapt to their needs, but that come with time pressure.

Re: The Start-Up Trap

#90

Post by pdeuchler »

megaduck wrote: post #61
ardit33 wrote: post #50

Wait, since when TDD become a best practice? I know this author is advocating it, but has 0 (zero) solid data or evidence to back this assertion. He is just trying to sell another religion. What I have noticed, TDD is being pedled heavy by RoR contracting shops that just care about billable hours and not vested if the startup or company is going to make it on the long run. I see often that it is the usually youngish…

I work at one of those "contracting shops" (Pivotal Labs), and I think you're misunderstanding the reason we push TDD so damn hard: It's not about speed. It's about predictability. Good TDD forces you into building loosely-coupled code that's easy to refactor and change. When new business requirements come in, the effort for implementing them isn't increased because of your previous code getting in the way. There's a…

I don't understand this. You give a disclaimer saying TDD won't make your startup healthy, but then your second paragraph implies that "Good TDD" is a silver bullet by "forcing you" into building "loosely-coupled code that's easy to refactor and change".

TDD can test a monolithic `public static void main(String[] args)` just as well as the most dainty collection of python scripts. In fact, assuming you wrote the two to behave the same, your tests wouldn't know the difference. Isn't one of the larger problems of TDD that it simply tests quantifiable results, not profile the machinations of the code?

Writing truly good code is hard. It takes time, practice and a wealth of knowledge... No "process" (as the GP states) will shortcut these requirements for you.

Post reply on HN