Categories
decisions other process

AWS vs Azure support

We are testing migration to cloud. The long tech list of requirments is met by both clouds. But in our experience Microsoft wins in terms of suppoort which is by default phone based walk throughs while (paid) Amazon support defaults to emails that tend to be imprecise while their documentation is supperior (with cool Kindle integration). Assuming this is reflection of their cloud strategies (MS keen to build capability and customer base while AWS is optimising) pick the one that is aligned with the stage of your development.

Categories
decisions other

365 + Active Dir

Cloud is simple, right? It just works. Well… no!

Corporates love Outlook. The other reason you would pick Office 365 is the fact you get… Office. But Office 365 is not a cloud native. It’s more of a hybrid trying not to offend old school IT while trying to compete with Gmail.

Think hard if Outlook delegates are worth the work to get on prem IT working with the ‘cloud’.

Categories
behaviour decisions innovation other

Loser’s Game Programming

Tennis pros win based on the positive actions they take: unreturnable shots down the baseline, passing shots, service aces, and so on. We (beginners) try to emulate our heroes and fail… We hit our deep shots just beyond the baseline, our passing shots just wide of the sideline, and our killer serves into the net. It turns out that mediocre players win based on the errors they don’t make. They keep the ball in play, and eventually their opponents make a mistake and lose the point.

Tennis pros are playing a Winner’s Game, and average players are playing a Loser’s Game. These are fundamentally different games, which reward different mindsets and different strategies.

The smart novice programers play a Loser’s Game, where the greatest reward comes to those who make the fewest and smallest mistakes. That’s not very exciting but works.

What is the best way to succeed? As in all Loser’s Games, the key is to make fewer mistakes: follow examples closely, pay careful attention to syntactic details, and otherwise not stray too far from what you are reading about and using in class. Another path to success is to make the mistakes smaller and less intimidating: take small steps, test the code frequently, and grow solutions rather than write them all at once. It is no accident that the latter sounds like XP and other agile methods; they help to guard us from the Loser’s Game and enable us to make better moves. Search Eugene Wallingford for more info.

Categories
decisions other process

Micronumerosity

Small sample sizes reduce precision of estimation. Try to acquire more data but avoid simply adding “more of the same” as obtaining lots of small samples from the same population will not help. Applied more broadly: seek different opinions to avoid confirmation bias.