I clicked through and thought you were being too harsh. I mean, it can be fun to make toy implementations of things as an exercise. Doing an SSH server in PHP would be entertaining if you liked PHP. You'd learn something.
And then I read that his hacked-together-in-3-days ssh server was for use in production. In a hosting service.
> And then I read that his hacked-together-in-3-days ssh server was for use in production. In a hosting service.
That sounds like a brilliant technical guy, capable of running with a daft idea to completion (unlike me, with my collection of at-best-half-built personal projects), who should have some layers of protection between him and Real World Production...
"Now, people who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. "
Inexperienced (young) programmers don't know what's been tried, and what's available. I've been dealing with this a lot at work recently, where we ended up doing poor reimplementations of off-the-shelf stuff due to a mix of ignorance, and honestly, a bit of hubris.
It's a good attitude to have in academia/non-production critical work, but the GP is right, production demands a more conservative approach, especially when money/safety is at stake.
The type of ignorance Joel writes about (see parent) is different, it's more like "slavishly following design patterns" and "writing copy-and-pasted, improperly factored code". Both are ignorance, but the first is better called "NIH", whereas Joel's is, "writing bad code".
The part of "running a SSH server that you wrote in PHP in production" that is scary is not the "in PHP" part.
It's the "that you wrote" part.
No matter what language you write it in, you are going to mess something up. The OpenSSH guys have messed up working a lot smarter and more diligently and with more time than you have.
This is so very true, OpenSSH is probably one of the most secure pieces of software around. It has extremely high value to attackers, yet has had extremely few remote security holes in its lifetime.
They've invested years and many talented people in developing such a piece of software.
If you want to write your own ssh server in php, you should probably consider your motivation and how you can re-use their code or operate through it instead if your purpose if anything other than experimentation.
You shouldn't be using OpenSSL unless you are an expert in crypto and software development. It's not easy to use and it shouldn't be.
I can't say those difficulties he had in using the library were put there on purpose to keep people like him out, but it seems to be a good effect here.
Yeah, I'm still trying to figure all that out myself.
There was some allusion to needing some kind of database backend for the SSH server, but there are multiple solutions for that now (like LDAP).
I'd love to have this guy work for me in a junior role (because he can really crank out the code), but all his work would need to be reviewed, and I wouldn't want him to be making architectural decisions on his own.
well, is it better to have a hacked MVP released in production, or spend forever making it and never actually releasing it and then missing the window?
I can tell you absolutely, without question, that when it comes to security and people's funds, there is nothing courageous about a hacked MVP in production. There's a difference between someone's to-do app one weekend, and this case. If you are handling people's money directly or indirectly, you need to care about that and take it seriously. Or don't ship.
Well I would argue that the "M" in MVP would necessitate never losing anyone's money. If I were going to create a trading platform, I'd probably start with one that only accepted Play Money.
Well when mtgox started off btc was play money, it was always play money until perhaps 12 months ago when it became serious money. And I base play and serious on the value, at $10 a coin it was still fun, at $100 a coin I had to seriously consider how much I should keep on my phone or any other single place.
Putting on my Lean Startup hat for a sec, I would even say that the M could allow for losing money. If it's early on and your customers are all in the 2 1/2% of innovators, they will put up with a little of that. Certainly if you make them whole, but probably even without.
That said, "flawless accounting" would be very high up on my feature list. I think the failure here isn't launching without perfection; it's operating at scale without perfection.
I've been wondering whether the "M" in "MVP" is for minimum quality, or minimum feature scope.
I think minimum feature scope doesn't necessitate poor-quality software, just solutions that don't do everything for everybody. It's much better to ship a small feature set with very high quality, IMO, than a big feature set with low quality.
In the Lean Startup sense, the M is about minimum effort, and the V is about viability with customers. You're basically playing Battleship trying to discover where those two Venn circles overlap.
Different aspects of quality map to both those circles. There's build quality, which relates to the sustainability of the code base. There, you have to consider both short- and long-term quality. [1]
There's also quality as users perceive it. That varies widely by domain by market, and by how far you are along the adopter curve.
My general answer is the same as yours: minimal features with highly sustainable code. But for experiments, I think you can get away with terrible code as long as you a) throw it away quickly, and b) you are on it so even if you have a bad MTBF, your MTTR is really good.
I also think that you can tactically discard certain kinds of user-side quality. E.g., if I'm making a product for early-adopter financial traders, I'm not going to worry about quality of visual design, and I might inflict hard-to-learn interfaces on them. But I'd be rigorous about accounting and about UI issues that might lead to mistaken trades.
Oh, that's easy. The best thing is to use the off-the-shelf SSH server, one that has been written by experts and carefully reviewed by a lot of people.
Or do you mean this as a metaphor for MtGox? In that case, I would say that I would rather miss the window than be the famous asshole who -- oopsie! -- lost $500 million of other people's money.
The problem is less with a minimum viable product, and more with a far-from-viable product, in ways that aren't immediately obvious. The security FFVP is especially dangerous.
Depends on what the product itself is and from which perspective you're asking the question. At any rate, those are almost never the only two choices...
One way to look at ordering features in early products is as risk reduction.
One of the biggest risks is, "nobody gives a fuck", which is why MVPs are so valuable. It lets you test market hypotheses.
But if you're building something handling real money, then a pretty obvious risk is, "The system will lose money beyond our capacity to absorb losses." Their failure to address that risk here is at best negligence.
But given the size of the loss, I don't think we should rule out fraud. The interesting question is, "When did they know they had a problem?" Sometimes shitty accounting systems are just naiveté. But when they persist over a long period of time in a way that just happens to cover up loss, embezzlement, or theft, then it's worth asking: did they keep the shitty accounting because better accounting would have forced them to admit something they were hoping to cover up?
I wouldn't today, but the wright brothers did, because if they hadn't, someone else would've done it instead. If you wanted to be trail blazers like the wright brothers were, you might have to put up with a hacked together MVP. I m just saying that anyone who lost their money did so knowing the risks (or should have known the risks).
And then I read that his hacked-together-in-3-days ssh server was for use in production. In a hosting service.
Wow. Just wow.