Here’s an OLD story about famous scientist Richard Feynman, who had fun cracking the safes of all his fellow scientists working on the Manhattan project in WW2:
http://www.cs.virginia.edu/cs588/safecracker.pdf (this is a long read best left for an evening at home).

What’s interesting is how easily you can draw parallels to the security issues we face today.  You could almost swap the word “safe” with “web application”, and “atom bomb design” with “financial data”, and the story almost carries over to today. These safes/filing cabinets contained documents relating to the atomic bomb (ie: something worth protecting).

In Product Development, we sometimes speak of “hiding the Sausage Factory”, meaning “hiding the complexities of software development and release” from our users. We want our users to enjoy using our products - they don’t need to know all the trials and tribulations it takes to get there.

In our Product Development Factory, we define standard processes and workflows, to bring some efficiency, consistency, and predictability to our work. However, we’re human - we’re not interchangeable cogs. Someone goes on vacation, people change roles, people move on - the successor may not do the same things in exactly the same way. There is an unwritten first step in every process: “Think”.

After seeing the simple Automatic Fish Feeder on Thingiverse, I immediately ordered the required parts and set about modifying the design for my purposes.

I liked this particular design, as we only have a 2 bettas in 2 bowls, and we need to ensure only a couple of very tiny pellets drop with each feeding.  I did want to make a few changes.  It was not clear how the motor was controlled in the original design - I wanted to use an optical slot sensor to detect when to start and stop the rotating disc.

I recently came across this article:
My 20-Year Experience of Software Development Methodologies

The author discusses the methodologies he’s followed on various projects through the years, discusses the issues with each, and, presents that these are “collective fictions” that allow development teams to collaborate, an idea presented in the book Sapiens to describe how societies function in larger groups.

It’s an interesting read, and also interesting to reflect, on the changing processes and models used since I started working in software development. In 2006, the organization I worked for talked about reaching CMMI Level 3, and following a waterfall development model. By 2013, we were attending sessions on Six Sigma. In recent years, the interest has been in Agile/SCRUM.

My kids are both avid readers, but neither have been good with maintaining a reading log, sometimes requested by their teachers.

I thought if I reduced the effort required to maintain the reading log, they’d be more likely to track the books they read.  I created a website where, using a smart phone, they could just take a picture of the bar code on a given book.  The website would read the bar code, and make a call to the Google Books API to retrieve the book title and author, and add it to the reading log.

The kids are always drawing characters and writing, and I was wondering - could we use this to make a game together?

It turns out, we can.

I’d guess in about 30 hours, we’ve put together a small world where:

• The player can wander around our world
• The kids have both drawn characters that appear in the game
• My 7 year old has designed a couple of maps
• Together with my 7 year old, we have written some dialogue
• I figured out how to build out some simple logic, connecting scenes

First, I looked into various game making tools.  I ended up using Stencyl, the first one I tried.  I checked it out first because the free version is limited only in that it only allows you to publish your game to the web (as opposed to desktop or mobile versions), and, for me, a big bonus was that it runs in Linux.