Why I love Haxe

I’m a proud Haxe developer. Haxe has been my tool of choice since 2014, and I’ve never felt that I needed anything else. However, I have this conversation all too often, why am I not using Unity?

Rather than try to tear down Unity, I’ll explain why I love Haxe so much.

Write Once, Use Anywhere:

When you write code in haxe, it can end up anywhere. While this can mean running on any operating system, which is a major point for Haxe game engines, its a bit more than that. I wrote code for one of my games that happened to be useful for a client’s website. I just copied it over and despite that the game being native C++ and flash, it worked as is in my php server. Javascript can almost make this claim, but not when the target doesn’t have a node instance already, and Unity isn’t meant for use outside of gaming at all.

Light Weight:

If your project will span more than a few class files, the overhead of Haxe is minimal, thanks in no small part to its very powerful dead code elimination. If there is Haxe functionality you don’t utilize, it won’t be in the compiled code. This is fantastic for web games and apps where users are constantly re-downloading assets. QWOP ported to the Luxe engine using Haxe for this reason, and while engines like Unity have come a long way, its hard to beat a tech that’s been targeting the web since 2005.

 

Nothing is hidden:

So much of the Haxe ecosystem is open source and freely available. This was extremely attractive for me because I like the idea of being able to learn things like rendering and systems on the low level versus just using them and hoping they will work the same way for all of time!

To date, I have rebuilt engines in Haxe, and helped with the creation of the SDG engine I use every day for my RTS Framework. Things that the open source nature of the projects enabled me to dive into.

I’m a rebel (or at least like to think I am):

There is no shortage to the honest truth that I love working with an obscure language instead of the main stay of the industry. I take pride in that, but I’d never have stayed with it if not for the substance I found in this ecosystem.

Community:

The Haxe Community, which I encourage you to join, is full of great and impressive folks. I love working with these folks and the collaborative spirit they all have. I have to say I love watching the haxe.io Ludum Dare articles and seeing all the great games that are being made in Haxe each jam. It’s been a great thing to witness, especially as its been growing like a slow burning fire.

So, considering Haxe? Do! Alot of great projects are being done in Haxe. Northgard, Dead Cells, and Papers Please to name a few! Its a great tool, and it has a great community. If you want a technology that can work with almost any situation, look no further than Haxe. Remember, its makes you a rebel!

Where Scrum adoption can go awry – pt1

So I’ve decided to kick off this blog a series about how Scrum can go awry, because sadly I’ve seen it far too many times, and I’d love to save someone the agony of ‘WHY ISN’T THIS WORKING!?!’

I’ve attempted to put scrum into practice many times over the course of the last 4 years, and I have found 1 way that has given me great success: Sticking as close to strict Scrum as possible.

I don’t say that to say you can’t throw your own spin on Scrum with your team, but if there is one thing that I’ve seen happen over and over, its seeing the idea that each team’s process should be different as an excuse to stray for the formula often far too early.

A classic example: Making Scrum master and Product Owner the same person. Often times organizations still want a single person doing all the ‘managerial’ organization for the team. Before I go off on a tangent of every very good reason you shouldn’t (lets be honest, enough has been written on the subject), I’ll tell you that I’ve done it successfully.

How? I was forced into that situation for 2 years, and finally I got the balance right. Obviously though 2 years to figure out a way to do that process productively is way too long, and really it highlights the fact that its not recommended.

I had to learn how to manage a backlog, acceptance criteria, and story point/velocity tracking along side fostering productive discussions, ensuring roadblocks were being addressed, and keeping from being so involved that the team didn’t learn to fix its problems itself. It was a HUGE skill set to learn, particularly with respect to keeping myself from being a traditional manager. And let me tell you, I’m glad to just be a Product Owner at this time.

That role separation is one of many things that is critical to Scrum. 2 years was entirely too long to learn how to subvert something that Scrum is built around. What’s more is that this is just one of many ways teams and organizations try to tweak it to their advantage, only to set themselves up for failure.

It leads to an interesting question: Why is it so hard to successfully tweak scrum? Is there some Scrum gods that bestows the miraculous gift of Scrum productivity only to those teams that practice it strictly?!

My conclusion, based on my experience, is that Scrum is not some miracle per say, its a winning formula. Just like any formula, if you remove one part of it, you need to replace it with something that is able to make up for each value it represents, which puts you in less treaded ground.

There are no guides to how to be a Scrum Master/Product owner for instance, and I can say that if I were to train someone all the things that I learned, it would take several months and sprints to impart that knowledge successfully because its a balancing act that requires a solid grasp of each situation that comes into play.

So why do we see this keep happening? Why do we see Scrum teams doing Not-Scrum things?

There have been two cases I’ve seen:

  1. The organization is unwilling to adapt to Scrum and trys to blend existing processes in with Scrum to get a (mutant) hybrid approach instead of examining each of its existing processes and figuring out if it enables a Scrum team.
  2. The team itself believes that since the team owns its process that it can change some of the Scrum tenants to be ones that they are more comfortable with.

The first situation is one that makes my skin crawl out of having experienced it, and I wish those same organizations would move to something like Feature Driven Development, or at least Kan Ban because setting the expectation of ‘this is Scrum’ when you won’t do the full process sets a bad example of what Scrum can really do.

Teams, however, making the changes themselves is dangerous and ultimately falls on the Scrum Master to keep inline. This is tricky because you want the team to be empowered, but Scrum process isn’t something that should be thrown to the wayside without VERY careful consideration, and more important still EXPERIENCE!

In Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland uses the martial art concept ‘Shuhari’ to really help explain when a Scrum practitioner should start to tweak the process to suit their situation.

The idea is that ‘Shu’ is the stage at which one does the process as close to its original intention as possible. A beginning Scrum Team should be allowed and expected to practice true Scrum and little else but. Once the team has done so for a while, and has an understanding for what the process does and some of its value, the team progresses to ‘ha’ where they can detach from some of the norms and some times improve the process for their team. Eventually, the team can get to ‘ri’ where they fully understand each part of the process and the values it presents and without following the processes per se can gain those values. These team’s are Scrum even without its structure.

They are also rare.

Most teams that I worked on never were able to properly get into the Shu stage, and I have seen some that believe, well before they’ve finished storming as a team, that they are at the ‘ha’ stage. I fear that is a dangerous road, as leaving the process too soon means having to learn a new process without appreciating what its replacing.  Such a situation cripples Scrum teams progression, and needs to be avoided at all costs.

While that belongs majorly on the Scrum Master to enforce, I believe that its something that organizations that have chosen Scrum need to echo as a company value that, that Scrum teams start with Scrum and nothing but, and only after mastering and understanding it, start to throw their own spin on the process. To do anything else is to accept Scrum will go awry, and the boons that come from it will fail to materialize.