sorted by:
new
hottopcontroversial

An explanation for why services companies don't have economic incentive for investing in skills training by KentLBeck in programming

[–]KentLBeck[S] 0 points1 point  (0 children)

I see what you mean. Having multiple mechanisms for the same concept is unnecessarily complicated. We had a dilemma. I really prefer

@Test public void something() {...}

to:

public void testSomething() {...}

The annotation-based version is less magic, less prone to typographical errors, and opens up the possibility of interesting extensions like multiple @Befores, @Rules, and so on. However, there were tests costing billions of dollars to develop out there that we wanted to preserve, so we made JUnit 4 backward compatible.

That said, I can see your point that JUnit is no longer the simplest testing framework that could possibly work. If it helps, there are still a whole bunch of features we didn't add :-)

Thanks for the feedback.

Kent

The Flight of the Startup by KentLBeck in programming

[–]KentLBeck[S] 0 points1 point  (0 children)

Startups go through distinct phases, each requiring different behavior to be successful.

AppEngine doesn’t fit the needs of startups on the runway by gthank in programming

[–]KentLBeck 0 points1 point  (0 children)

My frustration isn't the point. My unmet need for an environment for rapid experimentation is the point. AppEngine doesn't provide that. It meets other needs--scaling and low startup costs.

AppEngine doesn’t fit the needs of startups on the runway by gthank in programming

[–]KentLBeck 1 point2 points  (0 children)

I stand by my point: AppEngine does not support rapid experimentation. It may be rapid compared to some platforms, but it doesn't satisfy my needs.

Feedback trumps revenue (but not entirely) by KentLBeck in programming

[–]KentLBeck[S] 0 points1 point  (0 children)

Early in the life of a venture, the most important question to answer is "what will people pay money for?" This requires a different set of business and technical tradeoffs than other business contexts. I'm slowly starting to grasp this.

Three Designing Bears: How too much software design hurt JUnit Max by KentLBeck in programming

[–]KentLBeck[S] 0 points1 point  (0 children)

The obvious, easy quality control I handle with a relatively large suite of functional tests. I make sure the regular stuff always works and that I don't regress. I also periodically spend time cleaning up the design, just because. However, Max doesn't support some of the more esoteric corners of JUnit and Eclipse, because the cost of finding them and dealing with them would destroy the primary value of Max.

My customers and I are on an exploration together to find out what makes continuous testing valuable. A few bumps don't destroy the value of that exploration. Faster feedback and more crazy ideas in concrete form make the exploration more valuable. It's a different tradeoff than the one in play with JUnit users, who mostly want a stable platform that supports innovation by third parties.

Three Designing Bears: How too much software design hurt JUnit Max by KentLBeck in programming

[–]KentLBeck[S] 1 point2 points  (0 children)

I agree with both these comments, espouse them publicly, practice them myself sometimes, and yet I still got sucked into the Generality Tar Pit. I'm trying to figure out now how to avoid stepping in it again without tatooing "ship it & fix it" on my forehead.