Building an amateur esports team from the ground up may sounds like a cool idea, but it can be an arduous and frustrating task. Countless hours are spent soliciting solo queue strangers in the hopes that they will play for your team, only to have them say they aren’t interested. Even more difficult is when the few who do play, only play for a short time and eventually quit before you manage to gain even the slightest shred of traction with your team.
We find similar frustrations when dealing with modern day Software Development. A high level design that looks nice in theory may not work for a variety of reasons in practice. Bugs may occur in the code, customer requirements may change, the combination of which frequently leads to large overhauls in the original design.
Whether it is creating a winning team, or engineering efficient and user-friendly software, both tasks require what is known as a “scrum” based approach to development.
Iterating on old ideas
“One of my most productive days was throwing away 1,000 lines of code.” – Ken Thompson
A common mistake people make in software development is becoming overly attached to their initial designs and code. All too often, people attempt to “salvage” their old code by forcefully intertwining it with newer designs, with often times further exacerbating the same design problems while introducing a flurry of new ones.
Instead, code should be reviewed constantly and assessed with the assumption that they are merely a step in the software development process and seldom an end product. This is particularly true with the state of modern software products as a continuing service (that gets updated, patched, and improved over time) as opposed a single standalone software whose functionality decays over time.
In the League Championship Series (LCS), we see teams such as Counter Logic Gaming (CLG) make a similar mistake of keeping certain players for too long.
Despite the warning signs of eroding team synergy as well as burgeoning trust issues. CLG chose to keep their mid laner Link for the 2015 LCS spring split, only to once again fall short in the first round of the playoffs. These issues finally surfaced when link wrote an extended discourse, documenting internal strife within the organization, while also revealing his own long standing discontent with the state of the team.
Starting from his stint on CLG Black back in 2012, to his flashes of brilliance with the main roster during the LCS era, Link’s career is the epitome of CLG’s mantra of potential that was never realized. And while Counter Logic Gaming had multiple opportunities to explore new options, their adamancy ultimately cost them another LCS split, and leaves their fans wondering if CLG will ever regain their past prominence.
Avoiding Premature Optimizations
“premature optimization is the root of all evil (or at least most of it) in programming” – Donald Knuth
I will admit that even I am guilty of making this mistake, so I will preface this section with an anecdote. During the summer of 2012, I was interning at a startup in New York, and it was my first time doing web development outside of a classroom environment. In school, I was taught that code should always be optimized for performance in terms of time and memory. However, the more I tried to optimize, the more complicated my code became, and the harder it was to debug and test my code. It got to the point where a even small bug with an HTTP Get Request took an entire day to track down. Eventually, my mentor at the time explained to me that it’s better to start off with simple code, and make adjustments only when necessary.
In some ways, this problem is the antithesis of the previously illustrated one, in that one should not be so eager to make changes to initial designs without assessing the requirements first. An uninformed attempt at code-optimization can easily do more harm than good.
We find the LCS analog to this example with the Team Coast organization.
After losing 6 games in a row. Team Coast opted to bench their mid-laner Jesiz in exchange for former Vulcan/XDG mid-laner Mancloud. For the remainder of the split, the team continued to lose games, but instead of assessing their issues internally, they continued to seek replacements by benching both Sheep and Impaler in favor of challenger upstarts Konkwon and WelcomeToHeaven.
Aside from the questionable choices of replacements, the constant revolving door around Team Coast’s roster suggests an over-eagerness to pull the plug on certain players if things don’t go their way. Constant overhauls such as these are typically indicative of an organization’s failure to analyze their own needs and requirements before deciding on what, and if any, roster changes need to be made.
All things in Moderation
“Moderation in all things, especially moderation.” – Ralph Waldo Emerson
Perhaps I’m beating a dead horse when it comes to this saying, but it really speaks to just how much of a challenge it is to straddle the line between holding on to ideas for too long, and giving up on an idea too soon. But it is precisely those who have found this balance that have built some of the largest corporations in their respective industries. With that said, the information laid forth in this article is not a formula for success, but rather a guideline. Developing good software or assembling a winning esports team will ultimately require hard work and dedication, and possibly a bit of luck as well. Such is the nature of managing your own organization.
Mark Zuckerberg (left) and Andy Dinh (right) both made huge investments into their respective corporations, dropping out of school and devoted countless hours every day to ensure that they built their organizations properly from the ground up. For every Mark and Andy out there, there are thousands, even millions, of other young entrepreneurs whose dreams only remained dreams.
However, if I could inject one piece of my personal opinion, I firmly believe that so long as you enjoy the process of achieving your goals (whether is it in software or esports), the experience will be worth the effort, regardless of the final outcome.
