jmathes

I worked at a software company where we should have run an experiment like this. There's an upgrade on user accounts that we charged a one-time $10 for, and people buy it all the time. We decided to try it as a subscription.

We spent a month getting the subscription code ready, then deployed it to some % of users, only to discover that nobody wanted it. What we should have done was build the front-end only, get people to buy subscriptions, and then just grant them the one-time permanent version.

"Also, what size does a problem need to have to result in such a meeting? Every argument with your colleagues? Every customer related problem? Every technical problem?"

Disclaimer: I work at IMVU, but I am not the article's author This is a problem you have to solve for your own context. I suggest starting with only the biggest problems, and seeing how the process works for you. You'll see the people who are in those meetings getting accolades for their follow-up work, and you'll find that as the root cause analysis gets up to why #3, the participants are solving problems they didn't cause. Both of these will help to build the right corporate culture, as you mention. Then, if it seems appropriate, it will be easier to apply 5Ys to less serious problems, because their value will be well-known to the team.

Being mentioned in a 5Y here never bothered anyone. Because you know you have to come up with a fix for all five levels, everyone too preoccupied thinking up solutions to begrudge anyone.

I'm an engineer at IMVU, the company mentioned, since the inception of the 5Y strategy.

I've lost count of the number of cool technologies and tweaks we've built as a result of 5Ys. For example, occasionally one of our engineers will decide to build his own website, and use simpletest to unit test his PHP because that's what we have at work.

That engineer invariably complains about how bad out-of-the-box simpletest is compared to the house model we've cooked up. I've heard "It doesn't even have X!" many, many times. More than half the assertions in our php testing framework are custom-made, all the web gets and posts assert on the response code automagically, etc. And that's not even counting how much support we've ended up building into it for our other technologies - automatic detection for failures in memcache, SQL, and what-have-you. Or the other testing frameworks we've rigged to run within it, like YUI test and selenium. All because of 5Ys, and that's a minority of the good 5Ys have done for us.

In the long scale, it's like this: 10^3 = thousand 10^6 = million 10^9 = milliard 10^12 = billion 10^15 = billiard 10^18 = trillion

So there are 10^18/10^6 = 10^12 millions in a trillion. In the long scale, they'd call that a billion. So the two correct answers are "there are a million millions in a trillion" and "there are a billion millions in a trillion"

Scientific study shows that appearance is _correlated_ with winning elections. Journalist _opines_ that it's a causal relationship. Here's another possibility (just to illustrate the fallacy): maybe being better qualified and having better ideas gets people to vote for you AND it causes your appearance to change.

So "the education-preventing government control will continue until education improves?"

This guy is trolling. Please to not feed him.

Each test you write is a value-add. You get increased safety that what you're testing works the way you think it does, and that it will continue to do so as people modify it. Not all cases need to be tested; "test to your level of paranoia" is our motto. In the case of tests themselves, the value add for testing individual tests has never been worth the ROI. There are, however, tests for the testing _system_, insofar as that's possible (which it is, for the most part).

As for the "I happen to view TDD as a completely obnoxious and unnecessary exercise" objection, I'd be willing to bet you've never tried TDD. It doesn't take long for proper TDD to _save_ you time. Each iteration cycle is slower, but the marginal cost for adding new code to a complex codebase doesn't increase nearly as much.

Without TDD, you soon have to spend time on manual testing, and then you've got humans in QE basically practicing TDD for you, as the walk through script after script doing things that could be done faster by a computer. The only time it's appropriate to consider skipping TDD, IMO, is on tiny one-man projects.

Yes they are. Where he meant 1000a+100b+10c+d he wrote abcd.

Okay I'm only replying to this one reply but my point is relevant to all discussion re meaning.

Always be suspicious of any statement about numbers that relies on the base. This property of 6174 is really a property of the number's representation in base 10. In another base, it's the same number, but doesn't have the same property. That's why it seems suspiciously meaningless.

Whether you commit your code once in one batch at the end of the day or 50 times in 50 smaller chunks, you have the same amount of complexity about which to be careful. In fact it's more complex in the former case, because in the latter, for each push, you know that all the previous pushes are working.

I think the source of your confusion is that you're a one man team. You don't have to solve problems that 20-man teams have to face. At least half of all the code I depend on is code I do not understand, so I have to depend on its tests, and I have to make the same promise to consumers of my code. If my change breaks code someone else wrote that I didn't foresee, I am depending on his tests to tell me what I screwed up.

I work at IMVU as well, know the author personally, and can tell you that yes, he unit tests too. In fact, like all of us, writes all code test-first.

For test strategy in general, you need a whole seminar. There's a good blog on testing over at http://googletesting.blogspot.com/ <- go there!

As for code:test ratio, I'm not sure what metric you want, but using just php files, there are ~1k active test files and ~7k php files total. So if you take into account that 1k of that 7k is the test, and some is test-setup and obsolete files we no longer use, it's maybe about 5:1 code:test. However, a lot of the code is third party OS software packages. In-house code is about 1.5:1 test:code, in my experience. These, by the way, are very rough estimates.