ericevans

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.

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.

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.

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.