Okay, I almost wish I hadn't read this comment because it is so similar to what I have in part 2! So please don't be annoyed when you see it in a couple of weeks ;-)

I actually separated it into a separate part because it undermines my primary point. Sure, we all love it when we have a better decomposition, better names, and everything falls into place. But it doesn't always. Not in the time we have. So then we need ways to deal with the flaws. I decided that if I had ended with this it would have communicated: Aw, just keep trying and you'll get something nice! That can be very risky.

Heh. You didn’t have a perfect example but you went with what you had and shipped.

The only thing advanceBy has going for it is that when the programmer inevitably tries to type add (after wondering why plus turns up nothing), the IDE _might_ show it in a dropdown.

Ok, but that’s when you read the docs. Also, in many languages, those expected methods could be mocked out to raise compiler errors, redirecting the developer to the correct methods.

This is definitely the sort of idea that I like when exploring and trying to find a better model. The point I was trying to make in the article is that there are times when, however you try, you don't find a satisfying answer in the time you have.

Your point was good. But perhaps your unfortunate example is in turn a good example that if you can't find a good name for something perhaps there is a different way to look at things that produces a less contrived (but still explicit and honest) naming scheme.

Looking forward to read about your explorations on that front.

Yes, that was my point. Avoid overly simple names and also overly elegant names, unless you've actually found a simple, elegant concept.

I do have thoughts on better names. I'll write a follow up about that. But I didn't want to include it in this article because my most important point was that we need ways to curb our perfectionist tendencies, and not by hiding the rough spots. And if I had ended on that up note, it would have been the usual cheesy ending: Look! I'm so good that I always end up with a beautiful design. Which, as you say, was the opposite of the takeaway I wanted.

What would be a better example to make the point, do you think? I always use the best example I can think of. Obviously there must be better ones.

I was trying to be funny here! There is lots of room between "plus", which I think is misleading, and the kitchen sink name you quote. Although it depends on how serious the problems were, in this case I'd pick something shorter that still suggested rough edges.

Makes perfect sense, I thought so as well. It just made me think hope somebody doesn't assume this would be the best name in this case :)

It is interesting that many of the comments have suggested that JodaTime does what a "normal person" would expect in most of these odd cases, whereas you are pointing out that advanced mathematical concepts can define an algebra where associativity doesn't apply. Almost opposite points! But well taken.

One thing though: I think I was clear that I like Joda Time. It does handle these things better than most libraries. That is what makes it interesting to discuss. I could write a fun article picking apart some awful library, such as the old Java default library, but what would be the point.

The YC people deal with enough startups to see probabilities. They have data, and they say the odds improve dramatically with cofounders.

This article (mostly) doesn't dispute that, and explores ways to perhaps compensate for the lack of a cofounder and redress those odds a bit. That seems useful as a source of ideas, as long as we keep it in the right category.

It is in a different category from the YC statement, which was based on numbers. YC didn't draw conclusions about cause/effect, they just correlated. That's pretty solid ground. This article puts up several specific possible causes of the cofounder advantage and then possible solutions, which might work, if the cause/effect inference is right. Two layers of inference, based on anecdotal evidence.

The article made me think about the issue in a different way. I thought it was valuable in that way. I'd be really interested to know if people with data have correlated solo startup success with any other factors. Does anyone know of any such attempt?

They shouldn't "pardon". If there were some other form of nullification, that might be ok, but did nothing wrong by modern standards, and "forgiving" him implies that he did, even if that isn't their intent. And any legal relief a pardon would give a living person is irrelevant.

Let the conviction stand as a historical marker of shame.

Instead, they should vote on an apology to him and all the other people wronged by the actions of their predecessors.

> but did nothing wrong by modern standards, and "forgiving" him implies that he did

One of the purposes of the pardon power is to nullify convictions where a law was broken but the conviction, justified as it might be by the law, was unjust in the specific context.

Now, its designed (on the premise that the law is always just in the general case) to deal with exceptional cases, but it is no less appropriate a vehicle for the case where the law failed to be just in general and thus any conviction under the law is unjust in its specific context.