Essentials of Interactive Computer Graphics by Kevin Sung, Peter Shirley, Steven Baer is a good book for theory of how to work in and with interactive graphics. Their chapters include things like event driven programming, model view controller architecture, GUI APIs and working with the graphics APIs. I especially liked how they brought in real world examples like dealing with 3D modeling packages (Maya), abstracting behaviour of game elements and the number of examples available.
The book is a mix of Direct X and OpenGL, but there are lots of examples that make it worthwhile. This book is targetted more for a beginner to intermediate, but I especially liked the concepts of event driven programming in a book about graphics. So often, I find programmers from other disciplines and backgrounds (with the exception of real-time programmers) are not as concerned with event driven programming. Often, in application programming event driven programming may only be used for GUI elements, which in most cases is all that is needed. In a game however, there are often a lot of elements (objects colliding, proximity triggers, network sync events etc.) that cause a lot of events to be happening simultaneously, and having a good grasp on how to deal with these events and design code to work with these events becomes very important.
Good book overall, especially for those new to the concepts (and hopefully everyone has at least heard of model-view-controller).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Monday, November 22, 2010
Saturday, November 20, 2010
Unity 3.0 ShaderLab
Everybody loves shaders, and Unity's 3.X ShaderLab http://unity3d.com/support/documentation/Components/SL-Reference.html is interesting in what they have done (ShaderLab is similar to CgFX scripts, but unique to Unity).
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Sunday, November 14, 2010
Unite 10
I was at Unity's UNITE conference in Montreal, and it was both informative and fun http://unity3d.com/unite/ UNITE is an annual conference to showcase and educate users and developers using Unity technologies. This conference is the largest annual Unity developer conference and is the tenth such conference. UNITE is often the platform Unity uses to announce new releases and features, as well as gain feedback and interact with the Unity developers.
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Thursday, November 4, 2010
Book Review: The Art of Concurrency
One of the books I picked up recently is The Art of Concurrency A Thread Monkey's Guide to Writing Parallel Applications by Clay Breshears. The book itself is an interesting read, and Breshears is a funny writer, I especially liked the quote: "No evil threads, just threads programmed for evil". He also had some interesting examples, one especially vivid example of how code can interact was to think of two hands as threads, each finger as a line of code and how many different arrangements those fingers can be intertwined when clasping your hands together.
Breshears mentions threading as the future of applications, with multicore becoming more and more popular, and concurrent programming eventually becoming the norm for everything wanting to take advantage of all these additional processors.
The book talks about approaching concurency and threading with eight simple rules:
1. Identify Truly Independent Computations.
2. Implement Concurrency at the Highest Level Possible.
3. Plan Early for Scalability to Take Advantage of Increasing Numbers of Cores.
4. Make Use of Thread Safe Libraries Whenever Possible.
5. Use the Right Threading Model.
6. Never Assume a Paricular Order of Execution.
7. Use Thread Local Storage whenever possible or associate locsk to specifi data.
8. Date to change the algorithm for a better chance of concurrency.
There are also some talk of various threading libraries, OpenMP (implicit threading) , Intel Threading Building Blocks as well as explicit threading: such as pthreads and Windows Threads.
The book also shows some threading examples of sorting, searching, graphs, as well as some information on the Intel's VTune Performance Analyzer which sounds pretty useful in finding those hotspots that would be potential candidates for parallel computing.
Lots of interesting stuff, and the book covers quite a bit of different areas. I especially liked the eight rules and found the overarching view of the different areas of threading interesting.
Best of luck managing your threads,
Michael Hubbard
http://michaelhubbard.ca
Breshears mentions threading as the future of applications, with multicore becoming more and more popular, and concurrent programming eventually becoming the norm for everything wanting to take advantage of all these additional processors.
The book talks about approaching concurency and threading with eight simple rules:
1. Identify Truly Independent Computations.
2. Implement Concurrency at the Highest Level Possible.
3. Plan Early for Scalability to Take Advantage of Increasing Numbers of Cores.
4. Make Use of Thread Safe Libraries Whenever Possible.
5. Use the Right Threading Model.
6. Never Assume a Paricular Order of Execution.
7. Use Thread Local Storage whenever possible or associate locsk to specifi data.
8. Date to change the algorithm for a better chance of concurrency.
There are also some talk of various threading libraries, OpenMP (implicit threading) , Intel Threading Building Blocks as well as explicit threading: such as pthreads and Windows Threads.
The book also shows some threading examples of sorting, searching, graphs, as well as some information on the Intel's VTune Performance Analyzer which sounds pretty useful in finding those hotspots that would be potential candidates for parallel computing.
Lots of interesting stuff, and the book covers quite a bit of different areas. I especially liked the eight rules and found the overarching view of the different areas of threading interesting.
Best of luck managing your threads,
Michael Hubbard
http://michaelhubbard.ca
Monday, October 18, 2010
Coding Style and Stylecop
How important is coding style? This debate is something that really draws out the "artist" and critic in every programmer. In many ways the style of writing code is similar to writing poetry, and what makes the subject so hotly debated is that the beauty of the code, sentence or poem is all in the eye of the beholder. Just like those critics of of prose and poetry, the serious critiques of coding style come from understanding the limits and history of the form. Practice reading and writing lots of code, in different languages if possible, and acknowledging how many ways there are to write the same functionality.
In the same way that experimentation in poetry and prose makes for a better understanding of the overall form, understanding how different coding standards can make for better (or worse) code. With every coding standard the code will be limited but also potentially clarified in a new way.
Organization of code one way can make code reviews easier, but potentially making maintanability more difficult, code may be separated into different sections that are ordered in a certain way that causes significant scrolling, opening of multiple files and jumping through layers of code, that structured a different way may minimize bouncing around.
Coding standards for teams is especially important, and should be strictly adhered to as best as possible, for the overall benefit of the team. Consistency is very important as being able to quickly jump into a new class, module or section of the code "should" be as easy as jumping into a section that you wrote yourself. Coding standards are an agreement between programmers to create a cohesive work, much like any collaborative effort, the final product should be a uniform work of art.
The most diplomatic way to handle this is often through adopting a tool that lets catches errors quickly and consistently. This also frees up code reviews to be on more important aspects like architecture, re-usability, error checking, design patterns etc. as non-adherence to coding standards often ends up becoming the main focus if the code strays too far from the standards outlined. These tools should also be part of the commit process, so that the code is rejected if it does not pass the coding standards (in certain cases some of these tools may have to have slight adjustments, as desired, but with a focus on consistency).
For those C# Unity or XNA projects some guys really like Resharper (30 day trial at http://www.jetbrains.com/resharper/) For a free style specific checker I like StyleCop: http://stylecop.codeplex.com/ there is a good amount of customization and easily embeds into Visual Studio. The information that is provided from the code checks make it easy to know the issue and change the code to follow the coding standards that have been setup.
For python there is pep8 http://pypi.python.org/pypi/pep8 and pychecker http://pychecker.sourceforge.net/ as well as a few more.
In general the style and syntax checkers are becoming quite popular (especially with scripting languages that don't compile) but regardless a good "style cop" will improve code quality, readability of all sections of the code, and allows everyone to focus on writing great code, instead of what it looks like in the end.
Until next time, StyleCop: that is all.
Michael Hubbard
http://michaelhubbard.ca
In the same way that experimentation in poetry and prose makes for a better understanding of the overall form, understanding how different coding standards can make for better (or worse) code. With every coding standard the code will be limited but also potentially clarified in a new way.
Organization of code one way can make code reviews easier, but potentially making maintanability more difficult, code may be separated into different sections that are ordered in a certain way that causes significant scrolling, opening of multiple files and jumping through layers of code, that structured a different way may minimize bouncing around.
Coding standards for teams is especially important, and should be strictly adhered to as best as possible, for the overall benefit of the team. Consistency is very important as being able to quickly jump into a new class, module or section of the code "should" be as easy as jumping into a section that you wrote yourself. Coding standards are an agreement between programmers to create a cohesive work, much like any collaborative effort, the final product should be a uniform work of art.
The most diplomatic way to handle this is often through adopting a tool that lets catches errors quickly and consistently. This also frees up code reviews to be on more important aspects like architecture, re-usability, error checking, design patterns etc. as non-adherence to coding standards often ends up becoming the main focus if the code strays too far from the standards outlined. These tools should also be part of the commit process, so that the code is rejected if it does not pass the coding standards (in certain cases some of these tools may have to have slight adjustments, as desired, but with a focus on consistency).
For those C# Unity or XNA projects some guys really like Resharper (30 day trial at http://www.jetbrains.com/resharper/) For a free style specific checker I like StyleCop: http://stylecop.codeplex.com/ there is a good amount of customization and easily embeds into Visual Studio. The information that is provided from the code checks make it easy to know the issue and change the code to follow the coding standards that have been setup.
For python there is pep8 http://pypi.python.org/pypi/pep8 and pychecker http://pychecker.sourceforge.net/ as well as a few more.
In general the style and syntax checkers are becoming quite popular (especially with scripting languages that don't compile) but regardless a good "style cop" will improve code quality, readability of all sections of the code, and allows everyone to focus on writing great code, instead of what it looks like in the end.
Until next time, StyleCop: that is all.
Michael Hubbard
http://michaelhubbard.ca
Saturday, October 16, 2010
Book Review: Agile Software Engineering
Agile Software Engineering by Orit Hazzan and Yael Dubinsky works largely as an undergraduate textbook, dealing a lot with how to teach and educate Agile methodologies in a learning environment. The book is broken up into progressively more involved steps with each chapter ending with a summary and reflective questions. There are also breakdowns of running an agile workshop and dealing with planning, time estimation, reflection. As a whole, the book is quite useful as a beginner-intermediate approach to agile, and would likely work well for teachers & students, as a lot of the structure of the book is related to setting up and teaching agile in a classroom.
One of the more unique parts of the book is how the book references different aspects of agile using the HOT (Human, Organizational and Technological) perspectives. I found that looking at different agile concepts through these filters a useful way to see how agile works on many different levels. The book is also good at giving examples regarding globalization and how organizational culture can be dealt with in projects that deal with outsourced or contracted work, and how agile attempts to address these issues by providing additional transparency and interactions. The HOT perspectives I found were especially pertinent in those areas.
My favorite example, however, was on the the chapter on Trust using elements of game theory, and where the Prisoners Dilemma is applied to a work environment. This was applied specifically to where developers choose to cooperate or compete with one another and results in three possible scenarios:
1. If both developers cooperate they will be more likely to succeed.
2. If only one developer attempts to cooperate (by learning the others code, helping the other etc.) there may be a success of the project, but potentially the one developer that choose to cooperate may not receive as much recognition (since time was spent cooperating instead of competing).
3. If both developers compete (do not help each other, do not learn each others code) there will be no integration of efforts and the project will likely fail.
Obviously the ideal scenario is where both developers cooperate with one another and are awarded equally. As a lead or manager it is important to recognize when and where this type of scenario presents itself, and attempt to foster cooperation over competition.
The book also points to a link to code of ethics at the ACM (Association for Computing Machinery) and while I was not able to find the original link provided in the book at http://info.acm.org/server/se/code.htm I was able to find a similar document on the same site at http://www.acm.org/about/code-of-ethics
Please allow me to delve into a small tangent here: while I personally prefer to not have to mention ethics directly to my team (in hopes that everyone plays nice), there is often a significant amount of emotion that developers have for their work, and some developers can be very defensive about there work, to the point of being difficult to deal with. This attitude is unfortunate as every piece of code can be improved, every single piece of code! There is no such thing as perfect code, just as there is no such thing as a perfect poem, or a perfect painting or anything else that requires design. Things like structure, patterns, organization of the code, variable names, comments, formatting, optimization and more, are all subject to interpretation of what is good and thus can vary greatly from developer to developer. As a team lead, I need the developers to cooperate on the coding standards, but even then there can be a significant amount of hubris in some developers which can cause internal clashes. I have been lucky in my attempts to be like "lukewarm water" between "fire" and "ice", but through my experience feel like a code of ethics may also be a necessity, especially in larger teams.
Overall, the book definitely fits the niche well of being a good learning tool for those interested in Agile methodologies, and is probably best suited in a group environment as many of the reflective questions would likely garner some very interesting responses.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
One of the more unique parts of the book is how the book references different aspects of agile using the HOT (Human, Organizational and Technological) perspectives. I found that looking at different agile concepts through these filters a useful way to see how agile works on many different levels. The book is also good at giving examples regarding globalization and how organizational culture can be dealt with in projects that deal with outsourced or contracted work, and how agile attempts to address these issues by providing additional transparency and interactions. The HOT perspectives I found were especially pertinent in those areas.
My favorite example, however, was on the the chapter on Trust using elements of game theory, and where the Prisoners Dilemma is applied to a work environment. This was applied specifically to where developers choose to cooperate or compete with one another and results in three possible scenarios:
1. If both developers cooperate they will be more likely to succeed.
2. If only one developer attempts to cooperate (by learning the others code, helping the other etc.) there may be a success of the project, but potentially the one developer that choose to cooperate may not receive as much recognition (since time was spent cooperating instead of competing).
3. If both developers compete (do not help each other, do not learn each others code) there will be no integration of efforts and the project will likely fail.
Obviously the ideal scenario is where both developers cooperate with one another and are awarded equally. As a lead or manager it is important to recognize when and where this type of scenario presents itself, and attempt to foster cooperation over competition.
The book also points to a link to code of ethics at the ACM (Association for Computing Machinery) and while I was not able to find the original link provided in the book at http://info.acm.org/server/se/code.htm I was able to find a similar document on the same site at http://www.acm.org/about/code-of-ethics
Please allow me to delve into a small tangent here: while I personally prefer to not have to mention ethics directly to my team (in hopes that everyone plays nice), there is often a significant amount of emotion that developers have for their work, and some developers can be very defensive about there work, to the point of being difficult to deal with. This attitude is unfortunate as every piece of code can be improved, every single piece of code! There is no such thing as perfect code, just as there is no such thing as a perfect poem, or a perfect painting or anything else that requires design. Things like structure, patterns, organization of the code, variable names, comments, formatting, optimization and more, are all subject to interpretation of what is good and thus can vary greatly from developer to developer. As a team lead, I need the developers to cooperate on the coding standards, but even then there can be a significant amount of hubris in some developers which can cause internal clashes. I have been lucky in my attempts to be like "lukewarm water" between "fire" and "ice", but through my experience feel like a code of ethics may also be a necessity, especially in larger teams.
Overall, the book definitely fits the niche well of being a good learning tool for those interested in Agile methodologies, and is probably best suited in a group environment as many of the reflective questions would likely garner some very interesting responses.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
Thursday, October 14, 2010
Creating a Great Team
Comparison time: Great Hockey Team and Great Programmer Team.
While I am living in Toronto, I will instead focus on the Vancouver Canucks as a great team example. What do they have?
Star Players: Henrik and Daniel Sedin, Roberto Luongo.
Solid Reliable Players: Ryan Kesler, Alex Burrows, Christian Ehrhoff.
Good to Decent Players: the rest of the Canucks
Up and Coming Rookies: Cody Hodson, Cory Schneider
Parting ways with those that don't fit: Kyle Wellwood
Decent managment: Mike Gillis, Alain Vigneault
Some explanations:
Star Players: These are your guys leading the charge. They will have the most experience, most skill and most dedication to the project. Having a few of these guys will inspire the rest of the team to work harder and better, and will likely be the ones you have to rely upon in times of need.
Solid Reliable Players: While the stars are working their magic, these are the workhorses of the team, dependable, reliable, and dedicated. While they might not have the skill and experience of the stars, it is unlikely you can get stars in every position. The better skilled these lines are, the better chance you will have of completing the project successfully.
Good to Decent Players: These are the rest, and they should be of varying skill level, but all capable in some way, notice I didn't include any bad players. To be in the NHL, you have to have some talent, it should be exactly the same for your company. A player that has no talent will not survive in the NHL or on any good team, and your team should be no different. Give people a chance, give them training, but if they don't have the capability (or the heart), it will forever be a weak link that could be filled by someone else that would help the rest of the team more.
Up and Coming Rookies: These are your juniors and new team members, there is always potential that these could develop into your next stars, or alternatively be sent back down to the minors. A sports team will often give a person an extended tryout, but that doesn't mean they have to make the team, if they aren't getting the job done.
Parting ways with those that don't fit: Sometimes a player can have some good skills, but just not be the right fit for the position they are looking for. Sadly at these times, it is important to do what is best for the team, and that often means parting ways with those individuals who could be useful (maybe with another project at the company) but not on the team as it is now.
Decent management: Just decent management? Sure, while I like the management in Vancouver, it is really the players that are the stars, not the management team. You need smart people at the top helping make the decisions, but unless they are helping score goals (or commit bug fixes) often it is better for them to just let the players do their job.
So what does this mean? Basically the best thing you can hope to do, is hire the best people you can at every position and turn them loose. If you build a team of just rookies and a couple of fourth liners, don't expect them to be able to compete in the big leagues. In the end, you always get way you pay for.
I keep hoping that Toronto will turn it around, but can't help but wonder where their super star players are?
Go Canucks, Go Leafs!
Michael Hubbard
http://michaelhubbard.ca
While I am living in Toronto, I will instead focus on the Vancouver Canucks as a great team example. What do they have?
Star Players: Henrik and Daniel Sedin, Roberto Luongo.
Solid Reliable Players: Ryan Kesler, Alex Burrows, Christian Ehrhoff.
Good to Decent Players: the rest of the Canucks
Up and Coming Rookies: Cody Hodson, Cory Schneider
Parting ways with those that don't fit: Kyle Wellwood
Decent managment: Mike Gillis, Alain Vigneault
Some explanations:
Star Players: These are your guys leading the charge. They will have the most experience, most skill and most dedication to the project. Having a few of these guys will inspire the rest of the team to work harder and better, and will likely be the ones you have to rely upon in times of need.
Solid Reliable Players: While the stars are working their magic, these are the workhorses of the team, dependable, reliable, and dedicated. While they might not have the skill and experience of the stars, it is unlikely you can get stars in every position. The better skilled these lines are, the better chance you will have of completing the project successfully.
Good to Decent Players: These are the rest, and they should be of varying skill level, but all capable in some way, notice I didn't include any bad players. To be in the NHL, you have to have some talent, it should be exactly the same for your company. A player that has no talent will not survive in the NHL or on any good team, and your team should be no different. Give people a chance, give them training, but if they don't have the capability (or the heart), it will forever be a weak link that could be filled by someone else that would help the rest of the team more.
Up and Coming Rookies: These are your juniors and new team members, there is always potential that these could develop into your next stars, or alternatively be sent back down to the minors. A sports team will often give a person an extended tryout, but that doesn't mean they have to make the team, if they aren't getting the job done.
Parting ways with those that don't fit: Sometimes a player can have some good skills, but just not be the right fit for the position they are looking for. Sadly at these times, it is important to do what is best for the team, and that often means parting ways with those individuals who could be useful (maybe with another project at the company) but not on the team as it is now.
Decent management: Just decent management? Sure, while I like the management in Vancouver, it is really the players that are the stars, not the management team. You need smart people at the top helping make the decisions, but unless they are helping score goals (or commit bug fixes) often it is better for them to just let the players do their job.
So what does this mean? Basically the best thing you can hope to do, is hire the best people you can at every position and turn them loose. If you build a team of just rookies and a couple of fourth liners, don't expect them to be able to compete in the big leagues. In the end, you always get way you pay for.
I keep hoping that Toronto will turn it around, but can't help but wonder where their super star players are?
Go Canucks, Go Leafs!
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)