Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "dead life cycle"
-
Just joined a skype meeting:
Me (software engineer): Am I audible?
Product Manager: Am I audible to you?
Business Development Manager: Hey guys, Am I audible?
After 30 minutes:
Me: Hey guys, Am I audible?
Product Manager: Am I audible to you?
Business Development Manager: Am I audible, guys?6 -
Biggest challenge I overcame as dev? One of many.
Avoiding a life sentence when the 'powers that be' targeted one of my libraries for the root cause of system performance issues and I didn't correct that accusation with a flame thrower.
What the accusation? What I named the library. Yep. The *name* was causing every single problem in the system.
Panorama (very, very expensive APM system at the time) identified my library in it's analysis, the calls to/from SQLServer was the bottleneck
We had one of Panorama's engineers on-site and he asked what (not the actual name) MyLibrary was and (I'll preface I did not know or involved in any of the so-called 'research') a crack team of developers+managers researched the system thoroughly and found MyLibrary was used in just about every project. I wrote the .Net 1.1 MyLibrary as a mini-ORM to simplify the execution of database code (stored procs, etc) and gracefully handle+log database exceptions (auto-logged details such as the target db, stored procedure name, parameter values, etc, everything you'd need to troubleshoot database errors). This was before Dapper and the other fancy tools used by kids these days.
By the time the news got to me, there was a team cobbled together who's only focus was to remove any/every trace of MyLibrary from the code base. Using Waterfall, they calculated it would take at least a year to remove+replace MyLibrary with the equivalent ADO.Net plumbing.
In a department wide meeting:
DeptMgr: "This day forward, no one is to use MyLibrary to access the database! It's slow, unprofessionally named, and the root cause of all the database issues."
Me: "What about MyLibrary is slow? It's excecuting standard the ADO.Net code. Only extra bit of code is the exception handling to capture the details when the exception is logged."
DeptMgr: "We've spent the last 6 weeks with the Panorama engineer and he's identified MyLibrary as the cause. Company has spent over $100,000 on this software and we have to make fact based decisions. Look at this slide ... "
<DeptMgr shows a histogram of the stacktrace, showing MyLibrary as the slowest>
Me: "You do realize that the execution time is the database call itself, not the code. In that example, the invoice call, it's the stored procedure that taking 5 seconds, not MyLibrary."
<at this point, DeptMgr is getting red-face mad>
AreaMgr: "Yes...yes...but if we stopped using MyLibrary, removing the unnecessary layers, will make the code run faster."
<typical headknodd-ers knod their heads in agreement>
Dev01: "The loading of MyLibrary takes CPU cycles away from code that supports our customers. Every CPU cycle counts."
<headknod-ding continues>
Me: "I'm really confused. Maybe I'm looking at the data wrong. On the slide where you highlighted all the bottlenecks, the histogram shows the latency is the database, I mean...it's right there, in red. Am I looking at it wrong?"
<this was meeting with 20+ other devs, mgrs, a VP, the Panorama engineer>
DeptMgr: "Yes you are! I know MyLibrary is your baby. You need to check your ego at the door and face the facts. Your MyLibrary is a failed experiment and needs to be exterminated from this system!"
Fast forward 9 months, maybe 50% of the projects updated, come across the documentation left from the Panorama. Even after the removal of MyLibrary, there was zero increases in performance. The engineer recommended DBAs start optimizing their indexes and other N+1 problems discovered. I decide to ask the developer who lead the re-write.
Me: "I see that removing MyLibrary did nothing to improve performance."
Dev: "Yes, DeptMgr was pissed. He was ready to throw the Panorama engineer out a window when he said the problems were in the database all along. Didn't you say that?"
Me: "Um, so is this re-write project dead?"
Dev: "No. Removing MyLibrary introduced all kinds of bugs. All the boilerplate ADO.Net code caused a lot of unhandled exceptions, then we had to go back and write exception handling code."
Me: "What a failure. What dipshit would think writing more code leads to less bugs?"
Dev: "I know, I know. We're so far behind schedule. We had to come up with something. I ended up writing a library to make replacing MyLibrary easier. I called it KnightRider. Like the TV show. Everyone is excited to speed up their code with KnightRider. Same method names, same exception handling. All we have to do is replace MyLibrary with KnightRider and we're done."
Me: "Won't the bottlenecks then point to KnightRider?"
Dev: "Meh, not my problem. Panorama meets primarily with the DBAs and the networking team now. I doubt we ever use Panorama to look at our C# code."
Needless to say, I was (still) pissed that they had used MyLibrary as dirty word and a scapegoat for months when they *knew* where the problems were. Pissed enough for a flamethrower? Maybe.6 -
The source engine is interesting, because it has reached that stage of life where it's old enough to be remarkable-- in the sense that it could be called 'legacy', a sort of milestone in development practices and thinking, both in software, and design.
That said, a better look at it might be from the lense of *uses today*.
A lot of former source engine (SE) devs are now going to unity or unreal, I don't blame them.
But it's interesting to examine examples of games that haven't.
One such game is the freeware "No More Room In Hell". A couple online play throughs shows a wealth of well designed maps (and an even greater horde of shovelware maps, but hey, you take the good with the bad).
The age of the engine itself shows. Even in games like Left 4 Dead the engine's age can be seen. This, in some respects has been a drag, but also a blessing. Where other games could rely on their effects, shaders, and other tech, modders, map makers, and designers have had to rely on wit and creativity.
Enter "situated environments."
In an age where many people desire to travel, to go places, and have grown up doing the exact OPPOSITE, there is a great desire for variety of locations in games: not merely 'environmental' in the shallow sense of a 'theme' such as 'lava', 'tundra', etc. But in the sense of setting in general.
We want places that are both out of reach and yet familiar. Fire-fights happen in city streets. Apocalypses happen in neighborhoods where the skyline is both broken and at once something we know by sight. Open air markets, grocery stores, neighborhoods, all of these provide the back drops of popular games and series such as COD, Battlefield, The Last of Us, and yes, the example game, NMRIH.
I call this idea of 'familiar but out-of-reach level design', "situated environments", because familiarity with them, but *lack of real life experience* with them, on a day to day basis, allows people's expectations to fill in the gaps.
No one for example would argue the layouts of 7 Days To Die are familiar, but most of us don't spend all day in a junkyard or a high rise hotel.
So they *feel* familiar. Likewise with Skyrim, the villages and towns, both iconic and strange, our expectations formed by cultural inheritance, hollywood films, television shows, stories, childrens books, and yes, other games.
In a way, familiarity-without-real-in-person-experience is a shortcut for designers, one that lets them play with the player's head-space, the players subconscious idea of how a space and setting *should* work, what to *expect* out of the area, how to *operate* within the area. And the more it conforms to expectations, the more surprising an overdesigned element appears to be, rather than immersion breaking. A real life example of this is people's idea of chernobyl. When they discover the amusement park and ferris wheel they're blown away by the juxtaposition of the wasteland that surrounds them and the associations ('nostalgia' as it were) that such a carnival ride carries for many of us. It simultaneously *doesn't belong* and is yet all at once *perfectly situated in the environment*.
It is to say 'surreal', which is adjacent to the idea of *being real*, in terms of our "perception of what is and isn't plausible, if not possible."
This is at the heart of suspension of disbelief, because in essence, virtual worlds are a lie, like fiction, and good fiction violates expectations in order to tell us truths about reality. As part of our ability to differentiate bullshit from reality, there is to say an element in our bullshit detectors (doubtless evolved over many 10's of thousands of years), that is designed to not merely detect what is absurd in our limited experience, but to incorporate absurdity into everyday experience. In that sense part of our rationality is the acceptance of irrational experiences, learning from it, and discovering 'a proper place for each thing' in the "models of the world" we all carry around in our heads. Eventually we normalize the absurd, it becomes the new reality, and what remains unassimilated becomes superstition (real or otherwise), a figment, or an anomaly.
One of the best examples I've encountered is The Last of Us: Left Behind, a good chunk of which is spent in a mall. And they nailed the environment perfectly I would say.
Or for those who don't own a PS4, a more accessible example is a map in NMRIH aptly called "the museum", and few words better do it justice than to go play it yourself--that is, if you really want to know what I mean by a 'situated environment'.
What better way, during this pandemic, to get out of the news cycle and into your own head? Sometimes the best way to escape isn't outside, it's within.3