I’ve caught the pragmatism bug.  Everything I do now is the most pragmatic way I can possibly complete the task.  This all started when my time started costing me money; when I started working for myself.  I like to think of it as “The product justifies the means”.  Today I’m going to briefly describe what I mean by fanatical pragmatism with some concrete rules I’ve been following recently.

What fanatical pragmatism is

Fanatical pragmatism involves pursuing the optimal product as cost effectively as possible, without cutting corners.  For anything non-trivial, see if there is an existing solution that can solve the problem.  For games, this involves using a 3^rd party engine, particle system, etc wherever possible.  It’s about solving the problems that need to be solved, in the cheapest way possible.

It’s good for developers as focuses them on completing as much as possible, as quickly as possible.  It’s also good for the business as it means the problems the business exists to solve are solved as cost effectively as possible.

What fanatical pragmatism isn’t

It is not about cutting corners to get to a solution faster.  Nor is it about ignoring long-term goals to reach short-term goals faster.  Fanatical pragmatism is not “cowboy coding” (rather it’s tangential to it) and it’s more about solving the businesses needs for the least cost than just getting things done quickly.

How scrum fits in

It fits in perfectly with agile development practices, particularly Scrum.  Scrum is a discipline-agnostic framework that gives developers the freedom to work within their own specific style.  For this reason, fanatical pragmatism works hand-in-hand with extremely short sprints and meeting changing customer demands.  It acts on high-level sprint planning (deciding what goes into a sprint) as well as low-level, day-to-day development such as exactly how to solve the tasks for a given sprint.  For this reason it can be embraced by both developers and management alike.

Some general rules

Some general rules I’ve found myself following recently:

• Broaden your knowledge.  I’ve spent the last couple of years running a software company focussed on web applications.  I’ve picked up a lot of skills that I’ve been able to transfer over to game development (and vice versa).  The broader your knowledge, the large the pool of resources you can draw from to solve problems.  The jack of all trades is the master of fanatical pragmatism
• Focus on the goal.  The key to keeping pragmatic is always looking at where you are heading.  Every decision from day-to-day task assignment to strategic planning should focus on where the team is heading.  All efforts should be in driving the team towards their ultimate goal(s).

Some general software development rules:

• Separate your concerns.  A big part of why MVC works so well for a game engine is that it keeps the obvious concerns (e.g. gameplay vs. rendering) separated from each other.  This keeps each person on the team focussed on their part of the problem domain and helps to reduce complexity as the software grows in size
• Clean Interfaces.  Keeping loosely coupled systems is a great way of isolating your code so that any mistakes made, or changes needed can be done with the least amount of hassle in the future
• Build strong architecture where it’s needed.  For some large, complex system’s it’s important to spend the time up front designing the architecture for the system.  This gives everyone a foundation to build upon.  This should only be done in rare situations though.  It’s easy to get caught in the trap of doing lots of big design up front, however fanatical pragmatism calls for this only when absolutely necessary, and enough information is known.

Conclusion

So that’s fanatical pragmatism in a nutshell.  Share your thoughts on the topic and let me know how you work best in achieving your goals.  I’m constantly evolving the way I work and I’m always looking for the best way to solve problems so please leave a message with your best practices.