fbpx

Too big to parse.

 

The Sony breach is massive.  Terabytes of data were grabbed in this most recently announced hack.  What’s been released so far isn’t the source code for the new FF game, or a 5 year plan for development of a new line of wearables.  What were’s seeing so far is personal, it’s people-stuff, employee stuff.  Letters from doctors justifying medical leave, email conversations between producers, the mundane data that collects during the operation of a business.

The sheer volume of paperwork and information that a small business generates and keeps on file is impressive.  Scale that up to an international corporation on the scope and scale of Sony, where departments are likely segregated and the entire system is assembled, patchwork, from different vendors and datasets and you are looking at a data storage and retrieval nightmare.  And KNOWING everything that got swiped, that’s beyond the scope of any single human brain.  You might know that “all employee records from the NY sat office from 1987 through 2011” were grabbed, but that’s not going to tell you that the hackers got a copy of the letter written by the doctor confirming the guy who manned the front desk needed medical leave to get a tumor removed from his spleen.  And that right there is the bigger issue.  Controlling, encrypting, purging and retrieving all of that information, determining what needs to be saved and what needs to get dumped is becoming critical.

As server space gets cheaper and processing power continues to rise, we have become horaders of data, of information.  There are some things that should be used, noted and discarded, but we don’t.  We save it all.  We save it in case there’s a lawsuit, we save it because we “might need it” someday, we save it because we are simply to lazy to spend the brain-cycles on deciding whether or not to hit the delete key.

Better regulation (not the governmental kind, just the joe-average controlling kind) of data, better ways to track and retrieve data and above all, better ways of internally encrypting data are going to be key issues in development coming up.

To Death Do Us Part…

Image from Stanchieri Family Law

 

Once upon a time, you shipped a game and you were done.  Your team was in development on the next title before your game even hit the shelves and if you made any serious mistakes, well, you were pretty much f*cked.  You could (and sometimes did) release a patch or two, but those were regarded as bad-form and best practices dictated that you polished your particular gem until it shone before you let the Gold copy out the door.

Since the advent of reliable broadband, however, this is no longer the case.  Small studios race to release an MVP (minimum viable product) and then keep polishing it with updates once it’s in the hands of their users.  This offers a unique opportunity, it turns what was once a monologue (much like a novel or a film) into a dialogue between the developer and the consumers.

But how do you gracefully close that dialog?  Do you ever want to?  It depends on the size of your team and the resources you have available.  If you’re a small indie team, with everybody working on the game in their odd hours, then an open and shut product may be what you need to focus on developing.  If you have the resources (say, you game starts getting the downloads needed to let everyone quit their day-jobs, or bring in additional personnel) then opening an maintaining a dialog with your games fans is going to help keep your game alive and viable for a much longer period of time.

But until you hit critical mass, you’re tied to that game.