Day one consisted of a bunch of idea gathering. My kiddos have vivid imaginations and most of the time when you talk about games they click right into minecraft mode and that’s about all they can talk about. While I am a big fan of Markus Persson and his work, I told the boys they should come up with their own unique story and game flavors.

I told them to begin drawing pictures and just talking out loud about what they were thinking they wanted from a game. As they talked I wrote down key words that they said that had to do with: game name, characters (antagonist, protagonist), environment, and story line.

One idea was… Game name: Lego Minecraft Characters: protagonist - Lego guy, antagonist - environment Environment: Total mutable world Cool idea but it has really already been done.

Another idea was… Game name: MnHAON (no idea where he got the game name) Characters: protagonist - trucks, antagonist - turtle Environment: A road with moving cars, etc.. much like a frogger clone

We ended the hour with a couple of really good ideas where we picked the one titled “MnHAON” and decided to move on it.

We also decided on using greenfoot (i.e. java) for the project based on the simple API and java being a pretty simple language to pick up quickly.

Tomorrow we are planning on:

• Create our scrum board and cards
• Creating a github repo for the project
• Creating the “theme” music using aviary
• Creating a greenfoot project and push it to github

Related posts: kid gamification - planning, kid gamification - day 2, kid gamification - day 3, the finale

Being a homeschooling dad who is a self proclaimed nerd comes with a great deal of responsibility and it also tools my children in extremely unique ways. We just brought our newest baby girl home (yes, she is awesome!) and I am taking 2 weeks off to help my wife with the adjustments that come with having another baby at home. One way I am helping is taking over the homeschooling for a couple of weeks.

I know what your thinking: 4 boys and dad, mom is cuddling with the new baby girl - video games, junk food and movies, whoo hoo!! Well, almost…

My wonderful wife hooked me up with a lesson plan and the directive: “If you just get one or two things done that will be great.” Looking over the curriculum I saw math, reading, handwriting(who needs that?), science (cool we can blow stuff up), history (really that’s where that subject should stay), and so on. I mean my wife has this thing put together so well I felt like I might actually be able to pull off teaching my kids something other than the Konami code (a.k.a the Contra code) or how to beat Zelda (which we did).

Something felt like it was missing. So for two weeks we decided to ditch history and replace it with developing a game from 0 bits to shared. I will be teaching my 6 and 5 year olds with the following in mind:

The constraints:

1. The source must be shared via github and in a compiled playable format with in two weeks.
2. The focus will be on creating, experiencing and sharing code not the framework or deep syntax itself (so we will be using greenfoot, gosu or something like them).
3. The two students will write all of the code using XP and scrum with an occasional booster script from me
4. The two students provide all of the content: music, graphics, story and code
5. We will have fun

I am really looking forward to taking on this challenge and will be chronicling it daily, so keep up with us and follow what we are doing. I know the boys and I hope that it will inspire other parents and kids to try it out and see how far a little creativity will take them.

subscribe to follow our progress

Related posts: kid gamification - day 1, kid gamification - day 2, kid gamification - day 3, the finale

I like the smell of mowed grass. It reminds me of things like spring, new things and that something just got done.

Most of us have lists. I call mine the “grrr” list (pronounced grrr). This is a list of things that constantly irritate you about the software you write but for some reason you just cannot stop to address it.

My personal software grrr list has things on it such as: rip out old data model and replace it with the new shiny one I just built, change doc-type on all of my sites - so that I can-haz HTML 5 or move all of my domain names to one provider.

The things on your grrr list are important because they cause you grief and no one likes a constant stream of grief (re: Frasier). Do yourself a favor and create a grrr list - and in moments where you could watch re-runs of Frasier instead do something on that list.

You’ll feel accomplished and less frustrated with the software you write. Then you can go outside and do something you’ve been putting off, like mowing the grass.

Ever stop to listen to a ticking clock? It’s one of those things you don’t hear unless you think about it, or someone asks you, ”ever stop to listen to a ticking clock?”

That seems to be much like some software deployments I been evolved with over the years. The software goes out into production and no one pays attention until the alarm goes off.

As devs pushing bits into the hands of our beloved customers, why don’t we take some time to listen to the tick of the clock. You can do this by checking the logs after a deployment, monitor cpu / memory usage or my personal favorite get a tool like newrelic and see what the impact of what you just pushed really is.

the take away: just because it was deployed to ”production” does not mean it’s done or you’re done - take time to look at what your software is doing after a release it WILL pay off.

Let’s be honest, we have a lot of code, right? According to guys like Michael Feathers: “code you wrote yesterday is legacy code” and Jez Humble: “if you’re working with that code only test what you impact - don’t try to generate coverage.”

So with all of the legacy out there who’s dealing with the underbelly of our software stacks, you know “the lowdown” where no one dares to go.

Seems to me we need to be a little like Captain Kirk. He wasn’t scared to go places where no one had been. A little unknown nerd history on the juggernaut legacy of Star Trek - Gene Roddenberry, the creator, wanted to build something that was an adventure while simultaneously conveying a moral point and political agenda. Kirk was one such character who could carry out that agenda.

Let’s pretend Captain Kirk was a night time hacker - what would that look like next to how the show played out:

The Plan

Captain: Crew set out to do something routine

Coder: Kirk decides, “Hey let’s do a twitter mashup in one of my existing apps. I want to be able to tell all of the ladies how cool I am in my yellow an black stretchy outfit.”

The Distraction

Captain: Somewhere along the way they get a call: “Planet O’ ladies are in trouble, only Kirk can save them, please hurry.”

Coder: “Crap,” says Kirk, “I have to create OAuth hooks, and it looks like all of the models in this app use .net SOAP web services and there are no flippin tests!!!” “efffffffffffffff!, The boss is gonna kill me!” Kirk exclaims.

The Moral Dilemma

Captain: The Captain must decide, should I follow orders and go or should I do the “right” thing and save the ladies, errr um, the planet.

Coder: Scratching his head he thinks: “do I give up on the app, this legacy code is gonna kill me. Or do I rewrite it so that it actually looks and works like software.”

The Decision (this is where a lot of us go off the reservation)

Captain: “Think of the lady planet, they need me! I choose yes! I choose refractor, regardless of the dangers i’ll face.”

Coder: “Think of the ladies, they need my fashion tips! I choose refractor, regardless of the dangers i’ll face.”

The Victory

Captain: He arrives, struggles with the bad guy aptly named SOAP (what, it’s my story) , looses his shirt (so that they can have a show that both the man and woman will watch), saves the planet, gets forgiven for getting off task, and there is much celebration.

Coder: He begins writing tests, refactor, test, refactor, kills the bad guy named SOAP, implements his twitter client, gets forgiven for a little scope bleed, builds a killer app, and all of the ladies rejoice because now they see that most of his fashion is based on a breakaway design.

As dangerous as it may seem we need to deal with the lowdown and be like Kirk.

the point: Go hunting occasionally - code smells are not hard to find and there will always be something to refactor.

… the boy who cried wolf, the emperor’s new clothes, or the honest woodman - what do all of these have in common? They all deal with the axiom of honesty, perception, and misdirection.

When thinking about the business side of software I tend to think about the lions without teeth; the things that are claimed as the highest importance from the loudest people.

So as developers how do we distill the true signal in all of the noise? How do we separate the lions with teeth who we should be paying attention to from the ones without the teeth that we should be able to ignore? Have a point. In a scrum shop, this is generally set by the product owner, but we as devs are responsible for helping our groups stick to it when the pressure rises.

Impossible you say? You’re thinking, “there is no way we could all stand behind one point, the business would implode.” Really? So does that mean personal budgets don’t work, or that companies like 37signals really don’t function?

When lions bite they will do everything not to let go, because they are hungry. They know that letting go = empty belly or in the business mind => my group’s priority = my passion; those are the real lions.

What about the others? That’s where histrionics enters into the equation; where deception takes over and reality steps out. Their business mind => my priority = my passion. Stay clear of them, don’t have anything to do with them - they tend to distort, disillusion, and distract from the “goal.”

run with this: get a point for what you’re doing, write it down where it’s in your face, get behind it, do it, stay away from anyone who want’s to usurp it.

I recently found out I am going to have a little girl. Given the back drop that my four other children are boys, that I was raised with more brothers than sisters and my chosen carrier is dev let’s just say I have trouble “expressing” emotions.

Emotions are for socially accepted people, a notion that many developers seem to struggle with - being socially acceptable, that is. So in any given dev team how do you deal with introverts and the socially challenged, when you as a leader should be, well leading (whatever that actually means to the people you’re leading).

You start by connecting on an emotional level. Try by asking what do they love about their job and what do they hate. If they give you service level answers at first start off by “actually” being real with them and tell them about your love/hate relationship with your job.

The take away: You’ll probably lean something you didn’t know; something you’ll actually be able to do something about.

Would you ever think a hand grenade thrown wouldn’t break, damage or destroy something? I think in software we tend to fight with grenades, blasting our way through things we don’t like.

Have you ever watched a war movie where the troops roll in and they start lobbing grenades, firing rockets, shooting first then asking questions and at the end of it all you see a “relief effort” swoop in and rebuild? No. After the dust has settled all you see is a bunch of broken stuff.

I feel like that matches the pattern of some of our dev-mentality. We go in with the intent of saving the village and all we do is cause a considerable amount of collateral damage then bail assuming there will be some sort of relief effort (QA perhaps).

Why do we sometime fight with hand grenades instead of knives; more like the tank and less like the ninja? It might be the glory of the battle or the sweet taste of victory (at least as far as the fight goes ); who really knows?

All software needs some degree of refactoring and sometimes huge reworks are a sound way to rid yourself of a looming / annoying problem area - but try to start by using a knife not a grenade / iteration not search and replace.

The idea… solving problems should be iterative not mass-blasting with collateral results.

I see this sign on the way to work every day and think: “really!? If the builders of the intersection know it’s dangerous why don’t they change it?” I imagine the response would be something like: ”It’s too expensive” or “you can’t just change a road…”

We deal with “scary” legacy code all the time. The fact is if it was produced by you or someone else that doesn’t matter; it’s that it’s there.

More often than not we generally try to stay away from the code claiming that it is toxic or that by touching we would cause unforeseen consequences - claiming “you can’t just change a road.” When, in reality, it’s just code; bits cast on the grid.

Knowing that there are dangerous intersections, why don’t we as devs do something about it, change it, rework it. We have a choice: we can continue to avoid those bits or choose to make them better.

Take this up as a challenge: count in a given day, week or month how many times you or someone else groans about a section of code, functionality, etc… that has been complained about before. Not that you’ll be surprised by the result but you may realized how complacent you and other devs have become about dangerous code you’re allowing your users to use.

Drop FUD as a tool and pick up something useful in it’s place (such as unit / integration tests or parallel deprecation).

I’ve been wondering… what it would look like if I could close my eyes and pull my physical application platform out of a 2D doc and make it 3D.

What if you could take a game like minecraft and build something like “appcraft” where you could visibly see where the weak points in your architecture are and what hardware / software relationships make up your app.

I’m not talking about some over blown UML but an almost touchable model of your software that you could actually walk through. Why would it be so odd to actually make a game of it as well others could attack your virtual stack and see if they could break it.

What would be wrong with “gaming the system” and doing software modeling inside of minecraft?

{end-of-line}