Depends on many things, but if the data appears "controversial yet conclusive" then you investigate more deeply until you have ruled out just about anything else. Long time ago, I was part of a research team that sat on a 3.5 sigma result that only got stronger when we got more restrictive with the data set. We ran for two more years looking for other explanations. I was in grad school and could only think "why don't we publish?!?!" but the more experienced folks won out and upon further review, no Nobel Prizes were awarded and the reputations and funding remained in place. I think the adage "you only get to cry wolf! once" applies here.
Thank you so much for this! Awesome little sim/game. Beyond my coding skills, but it would be lovely to also show some of the Lagrange points for the orbits. I've noticed (I believe) that I can get objects stable around L4/L5 (but not L3) But I may also be imagining things :-) Very cool!
Egads this is excellent! As others have mentioned, would love to see a 5x5 variation and also be allowed to "keep going" after getting to 2048 to see how far you can go. I was disappointed that it ended and I had about half the squares empty and -might- have been able to get a 512 on the board as well.
But just fantastic. Perfect balance of "speed when I want to blast through the easy levels" and "I need to think about the best next move" as well as try to construct an algorithm that helps get me to the endgame!
Look at the Wikipedia article for Scrum (development). It outlines this approach reasonably well, and is "easy" to implement (e.g. the developers will not reject this as "over process") Be agressive in terms of commitments (making and missing) and hold to the fixed timebox. I -highly- recommend a 1 or 2 week timebox (-not- 30 days) as it forces more decomposition and only has people commiting to what they really know. Do the demos. Focus on vertical slices of functionality (e.g. don't just build the breadth of the UI component, take a single button and get it working down to the DB (for example))
-force- the developers to use a CM system and as part of the retrospectives, review checkins/branching, etc. This can evaporate after you are convinced that they are using a CM system (a month or two?)
ask about unit tests (even if you know little about software) if you sense BS, then you have a real problem. If they are developing UT's as you go. This is a good sign. Your hired tester should be able to review unit test coverage breadth with you (plural).
hth
