<i>What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications.</i><p>What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts.<p>Try designing an enterprise production/distribution system where:<p><pre><code> - set-ups must be minimized
- backlog must be minimized
- inventory must be minimized
- trucks must be full
- warehouse space is limited
- deliveries must be on time, but not too early
- sales people must have stock on hand
- plant absorption must be maximized
- bills must be paid on time
- down time must be zero
- working capital must be put to the best use
- stockholders must be satisfied
</code></pre>
Say what you want about enterprise programmers, but they get stuff built that handles all of these while academicians fuck around with linear algebra and OO castles for years.<p>After this, Monopoly sounds like a day off. Great post!
No one here or on the original page seemed to consider they should design a Monopoly game on the net to be "fun." Especially since Hacker News is about and for entrepreneurs, it would seem natural to turn an idea like that into money. Monopoly is a game. It should be fun. It had better be fun, or the design doesn't matter because it won't sell.<p>What makes the game fun? Part of it is the interaction between players, laughing, joking, scheming, and posturing. How do you bring that to a game played over the net? Is text chat sufficient, or can you easily do voice? What do you display to the players? Certainly part of the board needs to be displayed. When I play, I like to see what people have for properties and money. Will I be able to see that Alice has a stack of $500 bills or that Bob has nothing larger than a $50?<p>The original question is a very cool thought experiment, imho. My initial reaction was that to design this, I'd want to sit and play some games of Monopoly to see what to include and to see what the game is really all about. I've played hundreds of games of Monopoly, but that's not the same as designing a fun game to play over the net. Running through this little thought experiment helps raise many questions about how the game will work. Does each player have a complete client, or is this a server based system (or is it somewhere in between)? How do you handle dice rolls? How quickly can people start a game?<p>You need to know what you're going to create before you start applying tools to create it.
"If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem. In the software development I do, the requirements are never perfect. I don’t demand that a candidate try to create an agile, iterative process on the spot, but I look for someone who knows when to say 'close enough, let’s move forward.'"<p>I think this is a great reason why most interviewing techniques fail. The interview is not a reliable model of the work environment. This is especially true given the fact that people love "gotcha" interview questions which are essentially brain teasers which require you to know some arcane trick to get the question right.<p>I have seen great candidates spend a lot of time trying to understand a simple problem in an interview. These are people who under normal working conditions would never waste tons of time trying to get a perfect spec before starting work. But, because of the types of interviews people try and pass over as being "reliable indicators of future performance" candidates get stuck trying to find the trick in each question. If you have a candidate spend their entire interview trying to tease out a spec it sounds like a better indicator of the low quality of the interviewer rather than the candidate to me...<p>When people start heading that direction in an interview, be sensible and say, "Do you feel like you need a complete spec before going on? I promise there's no trick I'm trying to get you to fix" and you'll get the response you're actually looking for.
<i>If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem</i><p>I don't know how long your interview is, but if its just an hour and if the game is as ambiguous as you seem to say it is, I think its the fault of the interviewer, not the interviewee. The interviewee doesn't know what your schedule is -- unless you tell them, "You must code monopoly by the end of this hour, warts and all". But otherwise, I think its reasonable to take the full hour on requirements. In real life, an hour on requirements doesn't describe if there should be a splash screen or not.
In my experience, it's already hard to get a good read of a candidate within 45-60mn without adding external entities.<p>Monopoly is not just an external entity, it's a pretty big one with tight cultural ties. If the candidates you interview were not born in the same country as you, the best case scenario is that they played Monopoly in a different language and the worst case scenario is they never played it.<p>I prefer to focus my interviewing on questions that rotate around pure coding (if that's what the candidate is interviewing for) and even then, I hardly find the time to dig as deep as I'd like.
I know this is kind of beside the point, but my response would ne pretty simple - I've never played Monopply, and have no idea of its structure at all.