Uncategorized

RPG Development Progress Pulse – Entry 2

Progress Pulse

Progress Pulse – Entry 2

Things have been pretty busy in real life the past couple of weeks, so I haven’t had too much time for working on this. However, for this entry in the progress pulse series I’ll talk about some of the challenges I had while looking at making a generic data (de)serialization API + implementation, and why I chose to make some of the decisions I did!

Which Tech To Pick?

I’ve felt burned in the past by trying to do data serialization for my game framework because it’s always created a barrier for refactoring once it’s in place (i.e. i change some data i need and now i have to re-make or migrate allllll my SQL data).

So I was thinking about how I plan to store game state, which I have written about, and then considered the implementations I had considered for persistent storage. One of them was a graph database called Neo4j, which has a JSON representation of all of its node data. Except… I’m not ready to commit to Neo4j just yet because I don’t want to feel tied down (like I used to tie myself down to SQLite). But my objects I’m creating *are* well suited to hierarchies of entities+components, so maybe JSON is a happy medium?

Here was my breakdown for starting with JSON:

Pros:

  • Very easy to get started with
  • (De)Serialization libraries available via nuget for free
  • Human readable which is great for creating, editing, and debugging
  • Hierarchical, which lends itself well to my data structures in memory
    • Should make refactoring easy (did a component change? only change that component’s data representation)
  • Could be a stepping stone for working with Neo4j in the future

Cons:

  • Writing is probably slow, especially if I want to just modify one chunk of JSON data
    • Likely will need to write whole JSON blobs out… But who knows if it’s slow, I need to benchmark it.
  • I suspect lookups would be slow
    • But… Maybe important data is cached in memory on startup? Maybe it’s not even an issue. Benchmark it.

Basically, I was left with a bunch of pros and a couple of cons that were really just speculation. Seemed like a great way to get started!

Lesson learned was to start with something that won’t keep you locked in, but is also just enough to get you going!

Start With Something Specific

I’m a sucker for trying to make really generic things in software. It’s an extreme I find myself taking because I want to make things as extensible and re-usable as possible. The side effect of it though is that sometimes I miss corner cases (and they end up being not corner cases in the general sense) or that I make APIs that suck to use because they’re so general and maybe they shouldn’t be.

I decided I was going to switch up my approach. I wanted to figure out how I could serialize and deserialize my item definition data. That probably warrants a brief explanation:

I want items (i.e. loot) in the game to be part of a system that can control generation of them based on game state, randomness, and pre-defined organization of loot. Some drops might be totally random common items. Others might be based on quest state and need to be very specific. Maybe there’s some that only drop at a specific time of day during specific whether after killing a certain enemy. This is what I’m shooting for. So the item definitions will contain information about how to generate a base item, and provide components that tell the game how to mutate that base item (i.e. set damage to a value between 5 and 10 and call it “Axe”). But there are drop tables that have weights associated with them that can link to specific items or other drop tables. This allows the game’s content creator to generate loot that’s like “When the player is in the swamp lands, common enemies drop between 1-3 items, with a 60% chance of those items being junk, 20% chance of those items being normal equipment, 15% chance of those items being magic equipment, and 5% chance of those items being powerful legendary equipment”. Drop tables are essentially nodes with weights on the vertices that point to other tables or specific item definitions. Simple 🙂

The reason I went with this approach is because I felt that even though some of the C# types I have might be specific to item definitions, the abstract structure of the types (i.e. entities with components on them) is shared across many different game systems. So if I can make it work for this one, it shouldn’t be too hard to do for the next.

Lesson learned was try not to repeat all of your history… Learn from it. Experiment with new approaches.

Hello Singletons, My Old Friend

My arch-nemesis Dr Singleton! Actually, way back I’ve written about singletons so I’m not TOTALLY against them, I just think that 99% of the time they aren’t actually what you need. Let’s talk about my little run in with them though.

I started custom writing some APIs for JSON serialization that would use Newtonsoft JSON behind the scenes. Based on the structure of my objects, I figured I was going to have some sort of recursive call system going on where children would have to tell their children to serialize, etc… Once I got this working for a simple case, I realized that Newtonsoft has custom converters you can set up. These use attributes to mark up interfaces/classes to tell the serialization engine to use particular converters when they encounter a type. (Edit: after writing this I realize that I don’t HAVE to use the attribute… which might make this whole point moot)

The problem with attributes is that I cannot control the instantiation of them. And because I can’t control the instantiation of them, I can’t control the parameters passed in via the constructor. In my particular case, I needed to create a singleton that this attribute class could access and use Autofac to configure the singleton instance. Essentially, I needed to register custom handlers into my singleton instance, and then the attribute class could pull the registrations from the singleton instance.

Ugly pattern? Yes. I’m not familiar with any other ways to pass information or access to objects when I can’t control the initialization of my object though. It’s buried deep down so it’s not like the API usage feels like garbage, but still wasn’t happy with it.

Lesson learned here was sometimes we end up using “bad patterns”, but if they’re limited in scope we can limit their “badness”.


Part 1 – Exploring Graphs and Trees

Graphs and Trees - Delta State Algorithm

Graphs and Trees to Start

I was chatting with my colleague about generating maps for a 2D role playing game the other day after getting super excited explaining picking ProjectXyz back up and looking into Unity3D more. He was expressing interest in algorithms for procedural generation and storing data in trees or graphs as an optimal data structure for the scenario we were going over.

It stuck with me though. I’ve been putting a lot of thought into game state management and wanting to address it by using a generic layering/stacking approach. By that, I mean that I want to find a way to take base game state, allow mods or plugins to overlay their state, allow game patches to overlay their state, and then save game data to be overlaid on top of all of that. Conceptually, I believe I can create a generic system for doing this stacking of game data, which I’ll be referring to as my Delta State Algorithm, but I’ve been struggling with a starting point.

But the trees and graph concept stuck with me because the properties of trees and graphs that my colleague was referring to seemed to line up with how I envisioned this algorithm working. A graph or a tree just might be the right structure to represent this game state and the deltas between them, so I wanted to start mocking up some ideas.

A Map is a Game Object… And so is Everything Else?

Confusing subheader? You bet. But it’s because it was an odd realization.

I’ve been re-writing the same back end for an RPG for years now. Literally, it’s probably been at least 10 years that I’ve started, progressed, and scrapped such a game. But one thing I borrowed from Unity3D development was the idea of components and component-based design. I was far too married to object hierarchies, and these would eventually result in me having to refactor a TON of code. If you couple that with the fact I wasn’t using dependency injection properly (see this little primer article), it meant my refactoring efforts got to the point where it just made sense to start over.

So I was working with loading maps from TMX or Tiled map formats, and after getting these to load I was putting some thought into how I wanted to save/load my game objects. My game objects are essentially containers of components, and the containers have no properties at all. What does that mean in practice? My Actor/NPC game object class is the exact same class as an equippable item! It’s just “GameObject”. The difference between them is the variation in the components that I attach to them. In my mind, I figured I’d need some sort of hierarchical serialization paradigm where my game object would serialize itself, then the components would serialize themselves within that process, and if I could have components with components… You get the idea. But this could sort of be represented by a tree structure.

After the discussion with my colleague about trees and graph structures for maps, I connected some dots. Really the tiles and placed objects on a map were just… game objects as well. And that means that my thought process behind hierarchical serialization aligns well with some of the properties he was referring to for maps as graphs/trees. This suggests that “world state” for a game where everything is a “GameObject” with components attached to them (where some of those components can contain other GameObjects) could be represented by a graph or tree data structure

What About Tabulated and Listed Data Sets?

So we’ve come up with a starting point for “World Data” being represented by a graph. However, if we go back to my initial goal, I want plugins/mods/patches to be able to get applied to base “Game State” data.

What’s the difference between world and game state data?

These are just my terms so I should try and clarify. The world data is the data the player sees in the playable world. It’s the status of the objects and the maps they are interacting with. Game state data is the superset of this data and all of the other lookup data for loading content into the game. So this OTHER data includes things like the possible stats players and items can have, the types of monsters that can spawn (not the instances of the spawned monsters, because that’s the world state data), the possible dialog entries, etc… This type of data is really well represented in a relational database where we can create lists of data entries.

But if we take a step back, can’t that relational database content also be represented as a graph?

Could I have:

  • A node called “Stats” as a parent to a “Life” node that is a parent to a “StatRange” node, and “LocalizedNameResource” node?
  • A node called “BaseItems” as a parent to a “Sword” node that is a parent to a “DamageRange” node, “RequiredStats” node, and “EquippableSlots” node?
  • A node called “MonsterSpawns” as a parent to a “Skeleton” node that is a parent to…

You get the idea. I generally think about this data in a relational database paradigm (and perhaps it’s much faster to edit the data this way or look it up this way). However, if I can transform this data into the same type of graph structure I want to use for world state, then it means my delta state algorithm would work on not only world state data but also ALL game state data.

So Everything in the Graph? Always?

This is an important question, and I think one that without actually explicitly thinking about was causing me some headaches and keeping me from progressing down exploring more of my delta state algorithm.

I mentioned that some of the game state data feels better represented in a relational database. It might be much faster to add/remove or look them up when the data feels like it’s just a list of records when you contrast that with a graph. But why not have multiple storage mechanisms?

The delta state algorithm serves a very important goal: Layer deltas of data on top of a base set to get a new set.

That’s it though. So once I have that final transform of data that represents the new game state, who says I can’t transform it into a different format?

Maybe the world state is still better represented as a graph. So things like maps with tiles and game objects in the world still are super efficient to work with in graph form. Maybe things like dialog entries or definitions of player stats are better represented in a relational database… I could populate a database with the necessary data based on the graph data though. And the really cool part? A save game, which is probably the delta that changes the most, probably shouldn’t have the extra game state data in it (likely just has world state deltas represented). So… if a relational database is better suited for the remaining game state data, this could get generated and cached, and then only regenerated when different mods/plugins/patches are applied!

Concluding Thoughts

To summarize some of the major thoughts discussed in this article:

  • Game objects with components can be represented by nodes in a graph just like maps with tiles on them.
  • Other game state that feels better suited for relational databases can still be transformed into nodes in a graph for working with deltas.
  • Once a final game state is calculated (based on base state + deltas for mods/plugins/patches + delta for save game), data can be transformed back into the most suitable form to work with
  • Data does NOT have to exist in only one form! We can transform it as we need to work with it more effectively.

While this article was a bit of a brain dump, this the thought process that got the ball rolling for starting to design this delta state algorithm. In my next post in this series, I want to discuss a quick look at undo/redo approaches used in applications and how they might be similar (or different) to how the delta state algorithm might work.


Continuous Improvement – One on One Tweaks

Continuous Improvement - One on One Tweaks

Continuous Improvement – Baby Steps!

Our development team at Magnet Forensics focuses a lot on continuous improvement. It’s one of the things baked into a retrospective often performed in agile software shops. It’s all about acknowledging that no system or process is going to be perfect and that as your landscape changes, a lot of other things will too.

The concept of continuous improvement isn’t limited to just the software we make or the processes we put in place for doing so. You can apply it to anything that’s repeated over time where you can measure positive and negative changes. I figured it was time to apply it to my leadership practices.

The One on One

I lead a team of software developers at Magnet, but I’m not the boss of any of them. They’re all equally my peers and we’re all working toward a common goal. One of my responsibilities is to meet with my team regularly to touch base with them. What are things they’ve been working on? What concerns do they have with the current state of things? What’s going well for them? What sort of goals are they setting?

The one on ones that we have setup are just another version of continuous improvement. It’s up to me to help empower the team to drive that continuous improvement, so I need to facilitate them wherever I can. Often this isn’t a case of “okay, I’ll do that for you” but a “yes, I encourage you to proceed with that” type of scenario. The next time we meet up, I check in to see if they were able to make headway with the goals they had set up and we try to change things up if they’ve hit roadblocks.

No Change, No Improvement

I had been taking the same approach to one-on-ones for a while. I decided it was time for a change. If it didn’t work, it’s okay… I could always try something else. I had a good baseline to measure from, so I felt comfortable trying something different.

One on ones often consisted of my team members handing me a sheet of past actions, concerns, and status of goals before we’d jump into a quick 20 minute meeting together. I’d go over the sheet with them and we’d add in any missing areas and solidify goals for next time. But I wanted a change here. How helpful can I be if I get this sheet as we go into the room together?

I started asking to get these sheets ahead of time and started paraphrasing the whole sheet into a few bullet points. A small and simple change. But what impact did this have?

Most one on ones went from maxing out 20 minutes to only taking around 10 minutes to cover the most important topics. Additionally, it felt like we could really deep dive on topics because I was prepared with some sort of background questions or information to help progress through roadblocks. Myself and my team member could blast through the important pieces of information and then at the end, if I’d check to make sure there’s nothing we’d missed going over. If I had accidentally omitted something, we’d have almost another 10 minutes to at least start discussing it.

Trade Off?

I have an engineering background, so for me it’s all about pros and cons. What was the trade-off for doing this?

The first thing is that initially it seemed like I was asking for the sheets super early. Maybe it still feels like I’m asking for them early. I try to get them by the weekend before the week where I start scheduling one on ones, so sometimes it feels like people had less than a month to fill them out. Is it a problem really? Maybe not. Maybe it just means there’s less stuff to try and cram into there. I think the benefit of being able to go into the meeting with more information on my end can make it more productive.

The second thing is that since I paraphrase the sheet, I might miss something that my team member wanted to go over. However, because the time is used so much more effectively, we’re often able to cover anything  that was missed with time to spare. I think there’s enough trust in the team for them to know that if I miss something that it’s not because I wanted to dodge a question or topic.

I think the positive changes this brought about have certainly outweighed the drawbacks. I think I’ll make this a permanent part of my one on one setup… Until continuous improvement suggests I should try something new!


Recognition: One of Team Magnet’s Masterminds

Recognition: One of Team Magnet's Masterminds (Image by http://www.sxc.hu/)

Background

At Magnet Forensics, I lead an awesome team of people with the mission of creating forensics software to help investigators around the world solve crimes. We’re stacked with incredible people–and not only on the team I’m on, but company-wide. We do a great job of recognizing our achievements as an organization and as a team, but also on an individual level. If someone has gone above and beyond, we don’t keep that a secret.

I’ve been trying to make more of a conscious effort to recognize the people I work with, especially in ways that are unique to my own style. I think recognizing people in person is important, but you also need to consider your setting. Sometimes recognition in a public forum isn’t actually appreciated or isn’t nearly as effective as appreciating in a one-on-one setting. I find even for myself that I get uncomfortable when being recognized in a public setting.

With that said, I wanted to recognize an individual I work with without shining too much of a spotlight directly her. Thank you, Christine, for all of your hard work.

Broken Retrospectives

At Magnet, we try to adhere to some agile philosophies.  It lets us pivot pretty quickly to customer needs–which keeps them quite happy–and still lets us deliver rock solid software. We develop in short cycles called “sprints” and at the end of every sprint we have a retrospective to look back at what worked well and what didn’t. That way in the next sprint we can make improvements. Keep the good stuff, drop the broken stuff and try out a thing or two that’s new. This is excellent for continuous improvement unless…

They don’t work.

We would run our retrospectives religiously, but it seemed like nobody really wanted to be there. It was a seemingly forced meeting where I felt a lot of the time I was trying to stir up conversation. By the end of the meeting, just about everyone would have chimed in, but there weren’t a lot of ideas being generated. It was long, boring, and didn’t accomplish any of the goals we wanted it to. Thus, our development cycles stayed basically the same for a while. They worked and they didn’t appear to be broken enough that people wanted to see change.

Things remained the same until I received some input from Christine. When Christine read an article on LinkedIn called I Like, I Wish, I Wonder, she thought it might have some positive carry-over to our development process. If Christine thought that it might spark a change in our retrospectives, that was more change than I was hearing from the team in general (including myself, to be fair). So I decided we’d give it a shot.

Annnd we haven’t looked back since.

I won’t go too in-depth on how I Like, I Wish, I Wonder has rocked our retrospective world because I want to save that for a separate write-up. The point is that it did, and it’s all thanks to Christine for digging it up for us. We’ve started to completely overhaul different aspects of our development process now that retrospectives are effective. I really started to realize just how big of an impact it had when I was explaining some of the development process changes to our CEO. I remember thinking “Wow… If we wouldn’t have switched our retrospective process, we’d be nowhere near as efficient”.

So, thank you for the retrospective idea, Christine. For anyone else looking to flip retrospectives around, try out the I Like, I Wish, I Wonder scheme.

Personalities

I can imagine a lot of people in the development world don’t think too much about personalities. I know I didn’t. Sure, everyone is different. Everyone has their own effective ways of communicating, things they like, things they don’t like, and optimal situations for working. I get it. Now let me go do my work and you go do your work. In an ideal world, you just assume everyone can figure out everyone else that they’re working with, and things will just be fine. Except things are never ideal, and it never hurts to put in a bit more effort to make sure you can get your team up to speed.

So we tried something out. I worked with my HR manager (read: communicated a potential scenario for our development team, let her run free with her awesome creative ideas, and then helped her where she needed it) to roll out a Myers-Briggs personality test for a small sub-team of our development team. If you aren’t familiar with the tests or the concept, check out the link and read up on it! We figured it would be best to try this kind of thing out on a small part of the team to see if they would find value in it, and if so, we’d try the whole team.

After we rolled out the Myers-Briggs results with the small team, the benefits were immediately noticeable. We didn’t even have to leave the room before seeing the benefits. We knew there was some potential here, so we were already excited to try it out with the rest of the team. With everyone being aware of how other individuals may act and react when communicating and working, it makes a big difference in how particular scenarios are approached.

Thank you, Christine, for making differences in personality something to be cognizant of and then supporting our roll-out of Myers-Briggs. For anyone reading this that manages a team or is part of one… Consider the personality types of the people you work with. Maybe you don’t need a formalized Myers-Briggs plan, but it’s worth raising awareness of it.

Thank You, Christine

Christine, you’ve made a lot of great contributions to the team and I’d like to thank you for them. Our development processes have been able to greatly improve thanks to your initial suggestion. I’m sure we would have adapted over time, but your suggested tweaks have certainly acted as a catalyst. Your furthered support with the personality type analysis and subsequent rollout was also greatly appreciated. You were able to participate in our mini-experiment and offered great feedback to turn it into a success for the entire team.

Thank you. I’m looking forward to what this year will bring!


Charity Water – Weekly Article Dump

My 24th Birthday Wish - Charity: Water

Charity Water

We have a lot of pretty awesome people at Magnet Forensics, and every day I’m reminded just how awesome. A colleague of mine, Danielle Braun, had what I thought was an incredible idea for her birthday. For Danielle’s birthday, she’s not asking for more new clothes, for her parents to get her a car, for help with paying off tuition, or for some new fancy tech gadgets. But she’s not asking for nothing. Danielle is asking for your support with Charity: Water this year.

Charity: Water is a non-profit organization with the goal of bringing clean water to people in developing nations that don’t have access to it. Reading their mission page probably opens your eyes a fair bit about the lack of access to drinking water in other countries. They’re not about some complex and elaborate plan to revolutionize access to clean drinking water. However, they do have a simple and straight forward approach. Donate a little bit of money and they can install wells, rain catchments, and filters in areas without access to clean water. Your small contribution can make a huge impact on other peoples’ lives.

Please consider helping Danielle out with her goal of raising money for clean drinking water. A little bit goes a long way with Charity: Water.

Articles

  • Guest Post: 7 Deadly Sins: How to Successfully “Cross The Chasm” By Avoiding These Mistakes: In Geoffrey Moore’s article, we get to revisit some of the great learnings in Crossing the Chasm. If you haven’t read the book, although it’s a bit old now, it’s still a solid read. This post was a great reminder of a lot of the things the book talks about. It’s important to know where your business sits in the chasm model so that you know what you should be focusing on. Too many companies focus on the right things at the wrong times and have terrible missteps. Check it out (and the original book too)!
  • Holiday Gifts EVERY Employee Secretly Wants: Dharmesh Shah is a guy who always seems to have an awesome perspective to share. There are a few things that despite someone’s level of performance, length of employment, or amount of skill should be deserved.  Often these are overlooked either by grumpy managers or because perhaps the person may not have been a top performer. In Dharmesh’s opinion, that shouldn’t be a factor. The holidays are a perfect time to remind ourselves to recognize all of our employees’ accomplishments and treat them with respect. If you aren’t already, maybe this article is the little wake-up call you need.
  • 6 Things Really Thoughtful Leaders Do: Nothing groundbreaking here, but like the article says, this time of year is great for reflecting. Do you consider yourself a thoughtful leader? Do you observe the people around you, how they interact, and how things are flowing at work? Do you take the time to reflect on things you’ve done, how you’ve acted, or even how employees may have improved in areas you’ve discussed with them? There’s a handful of great reminders in this article that I would suggest you check out!
  • 14 Code Refactoring smells you can easily sense and What you can do about it?:  This week’s first programming article! Except… Well… This one is about the management side of programming. How do you know if your software team’s code is in a real stinky spot? This doesn’t necessarily mean your developers write bad code. It could just mean that you need to hit the brakes a bit and go revisit some problem areas in the code. This article talks about some of the warning signs.
  • What Makes A Good Manager? 7 Things To Ask Before You Promote: Does it make sense to give anyone you’re promoting a management position? Probably not. Seems obvious when you ask it like that, right? The unfortunate truth is that a lot of companies take the simple path and for anyone they want to promote, they throw a management position their way. Some people just don’t make great managers. This article talks about the qualities you want to look for in managers. Maybe the person you’re looking to promote won’t make a good manager *now*, but if it’s something they can put time and effort into building the skills and experience towards, it could still happen.
  • 10 Major Causes for Failure in Leadership: While lists of things to do are always nice, having a list of things to definitely not do is also helpful. Here’s one of them. Some of the leadership-don’ts I liked on this list were being too good to serve your followers, using your “authority”, and fear of competition. I think those are a few that are easy for people to forget, and there at the top of my list of leadership-don’ts. Read some more great points in the article!

Please take some time to help Danielle out with her goal. Any contribution helps. Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Code Smells – Issue Number 3

Code Smells – Issue Number 3 (Image by http://www.sxc.hu/)

Code Smells

Welcome to the third edition of Code Smells! Periodically I’ll be posting about how to detect code smells and what they mean in terms of the big picture of your code. The previous installment can be found right here.

What’s a code smell? Wikipedia says it perfectly:

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don’t currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

These code smells are often based on my own opinion and experience with programming. If you disagree with what I’m saying in my post, please don’t hesitate to post a comment. I’d love to clarify anything I may have worded poorly and discuss your perspective–especially if you have a completely different take on things!

The Stink List

Code Smell #7: Using exceptions to control logical flow. This is a pretty nasty path to get into and a bad code smell to stumble upon. Luckily, it’s generally relatively easy to improve. Using exception handling to control logical flow is, in general, misleading. It’s relying on a mechanism used to catch unexpected errors in order to direct the flow of your program. Often times we can use things like if statements to check for these conditions before throwing exceptions.

A common scenario where I see this is parsing. I’ll illustrate this code smell with a little C# example:


var input = "This is not a number";
try
{
  var parsed = int.Parse(input);
  DoSuccessfulStuff(parsed);
}
catch (Exception)
{
  DoFailStuff();
}

It seems a bit contrived, but I’ve seen lots of code written like this–and you know what? This works. It gets the job done. However, there are other mechanisms built-in to .NET that let us do parsing a little bit nicer:


var input = "This is not a number";
int parsed;

if (int.TryParse(input, out parsed))
{
  DoSuccessfulStuff(parsed);
}
else
{
  DoFailStuff();
}

The second set of code doesn’t need to catch exceptions to know that the parsing wasn’t successful. It may not be obvious from this example but throwing and catching exceptions can be quite expensive compared to a few logical sanity checks instead (and before getting into a debate on this, just know the impact it has on your program. I’ve had things go from taking several seconds to multiple minutes, but there are certainly cases where performance will be negligible).

The additional kicker in my contrived example is using the base Exception class to create what a colleague of mine refers to as Pokemon Exception Handlers. Thus, even if you didn’t want to restructure your code, using a specific exception type would:

  • Indicate to other programmers what you’re trying to accomplish
  • Not swallow other potential problems and have them go unseen

Now, this code smell isn’t always possible to avoid entirely. If you’re interfacing with third party components, sometimes you do have to rely on catching exceptions that you can’t otherwise check for ahead of time. If you don’t have the code, you can’t know for every path how/when/why exceptions will be thrown. The same thing could be said when running within an environment where state cannot be guaranteed. Sometimes it’s just necessary. In this case, I would suggest that instead of using Pokemon Exception Handlers, you try to catch the specific exceptions you know you need to watch out for.

Takeaway:

  • If a simple logic check can be used instead of throwing/catching exceptions, it’s likely a better bet.
  • Try to avoid exception handlers that catch all exceptions. Something nasty might sneak by as a result of it.
  • Interfacing with some code or working working in certain environments means you have to rely on exception logic. Take a deep breath and move on.

Code Smell #8: Having an object hierarchy that requires many very light weight classes. Object oriented programming and how object hierarchies are structured are pretty complicated topics of discussion, so I’m not about to try and over simplify it with discussion of this code smell. This is mostly something I’ve gathered from my own programming experience, so I’ll try to illustrate with examples that parallel things I would have come across.

When I’m building an object hierarchy, sometimes it’s not really apparent just how big and complicated it might get. I might start off with a base class and two child classes of it. Over time, the top three levels in my hierarchy have all turned into some sort of class abstraction, and I don’t hit concrete implementations until a few levels down hte hierarchy. Not a big deal–Sometimes it’s just hard to tell where things will go. When things get to the point where in order to introduce a new class and functionality all I need to do is inherit a class and override a single property or method, that’s a bit of a red flag for me.

On the surface, this seems pretty cool. The hierarchy is apparently solidified enough that extending it is really simple if all I need is a single property or method replacement. So why is this a code smell?

In my opinion, it has to do with the duplication of code. If I end up having many child classes (where child in this case represents the child-most class of my mature object hierarchy) that differ only by a single property or method, then I should look at how these classes are being constructed. I wrote recently about how I used lambda expressions to refactor similar code with classes that differed by a single method. My solution, in this case, was to examine the factory that created my classes. Instead of having 10’s of different child classes with a bunch of boilerplate code, I had one factory that could specify the code that differentiated each class.

The benefit of this?

  • Keep class hierarchies from ballooning our of control. Changing an API down the road can mean making changes in many spots.
  • Reduce duplication of boilerplate code. This might be the code required to define a simple constructor or override a getter property.

This is only one small example, but if you get into this situation in your class hierarchy, I’d recommend investigating to see if you can refactor in a similar approach. Maybe your class hierarchy is incredibly mature and isn’t changing much. If that’s the case, you may not even want to touch it. So be it. If you’re still actively adding classes to your hierarchy, it may be better to try analyzing it sooner rather than later.

Takeaway:

  • Object oriented design is a complex topic of discussion.
  • There’s no one perfect way to make your class hierarchies.
  • Having many child classes that differ by a property/method or two may be worth checking for refactoring opportunities.

Summary

I hope you enjoyed this issue of Code Smells. As always, it’d be great to open the floor to discussion. I don’t believe in absolutes, so identifying code smells is not meant to be me preaching some made up laws of programming. Let me know your thoughts on these code smells or share code smells of your own!


Performance Reviews – Weekly Article Dump

Performance Reviews - Weekly Article Dump (Image by http://www.sxc.hu/)

Performance Reviews

It’s almost the end of the year, and performance reviews for many companies are just around the corner. This will be the first time for me sitting on the other side of a performance review. I’m excited, and to be honest, a little nervous about how it will all play out. I know our HR manager has done an excellent job putting together our initial take on performance reviews, but it’s still going to be up to me to ensure that all aspects of a performance review are communicated properly to my team. It’s definitely going to be an interesting time of year!

I’ve started doing a little bit of reading on performance reviews. From what I can tell, the general consensus is that most performance review systems are flawed and nobody knows the perfect way to do them. That’s kind of scary actually. So, like anything, I started questioning all the aspects of performance reviews that I can think of. So things like: What’s stack ranking? Why do companies stack rank? What are alternatives? What about leveraging teammate-driven reviews? etc… There’s a whole lot for me to learn, so I need to start by questioning everything.

With that said, how do you do performance reviews? Have performance reviews been working at your organization? Do you stick to “the norm”, or do you have your own interesting spin on performance reviews that make them effective for your organization?

Articles

  • Employee retention is not just about pizza lunches and parties: On the surface, things like candy stashes, catered lunch, and all other shiny perks seem like a great way to get and keep employees. However, keeping employees engaged is the sum of what attracts them to the company and what keeps them motivated while they’re working. Recognizing their accomplishments and giving them challenging and meaningful work is an awesome start.
  • 7 Reasons Your Coworkers Hate You: The truth? You probably know at least one person at work who does at least one of the things on this list. The harder truth? You probably do one of these yourself. It’s a pretty cool list put together by Ilya Pozin. I’d suggest a quick look!
  • How To Inspire Your Team on a Daily Basis: In this article by James Caan, he echoes one of the things I wrote about recently. You can’t expect to have a motivated team unless you lead by example. You really shouldn’t expect anything from your tea unless you are going the lengths to demonstrate that your dedication to the team and the team’s goal.
  • humility = high performance and effective leadership: Michelle Smith write about how humility is actually a great leadership characteristic. A couple of the top points in her article include not trying to obtain your own publicity and acknowledge the things you don’t know. The most important, in my opinion, is promoting a spirit of service. You lead because you are trying to provide the team guidance and ensure every team member can work effectively.
  • The Surprising Reason To Set Extremely Short Deadlines: This one might not be the same for all people. I think that anyone that tries to apply this as a blanket statement is probably setting themselves up for failure. How do you feel about short deadlines? Some people tend to work really well under pressure and having short deadlines. For those that do, this article offers a perspective on why. Under pressure, you operate creatively given your restricted set of resources, and you don’t have time to dawdle and let things veer of track. Interesting to read.
  • Eliciting the Truth: Team Culture Surveys: Gary Swart talks about something I think is extremely important for all businesses. Maybe your work culture is established, but where did it come from? It’s easy for people to get together in a room and say “we want to have a culture that looks like X”. It’s harder to actually have the culture you say you want. Gary suggests you do a culture survey to actually see what your work culture is like because… well, who knows better? A few people sitting together in a room, or everyone in the company?
  • You Are Not a Number: With year-end performance reviews and the like coming up, I thought it would be interesting to share this short article by Dara Khosrowshahi. Do you stick to stack ranking? Do you have in-depth conversations with employees about their performance? Have you tried switching things up because the canned approach just wasn’t delivering?
  • Which Leads to More Success, Reward or Encouragement?: Deepak Chopra analyzes the positives and negatives of using rewards and using encouragement as a means of driving success. The takeaway from Deepak’s article is that using rewards is not a sustainable means to motivate your team, and actually tends to create separation within the team. By leveraging encouragement, you can empower your team to work together and self-motivate.

Remember to follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Lead by Example and Emulate Ideal

Lead by Example and Emulate Ideal (Image by http://www.sxc.hu/)

Background

Leadership has become a big focus for me as I start to grow more into my role at Magnet Forensics. As a developer, I feel like it’s easy to gain basic knowledge and experience with unfamiliar programming territory just by surfing The Internet. With leadership, that’s certainly not the case for me.

What’s my most recent realization? Lead by example if you expect anyone to take you seriously. As a young leader (and with little professional experience in a leadership role), I think this becomes especially important. When you lead by example, you’re showing others that you’re really behind what you’re preaching.

Lead by Example: A Simple How-to

Maybe it’s obvious, but I really don’t think I’m over simplifying my message when I say it. To lead by example, you just do what you expect other people to do. Obvious, right? If you’ve been working for long enough, you’ve probably had a boss that you thought was doing a poor job. There’s many reasons for this, and I don’t want to turn this into a negative-dwelling-unhappy-rant party, but one such reason is it felt like they were just passing down orders to you.

What’s more disengaging than having someone that’s locked up in a room come out every couple of hours to assign you a new task? This boss of yours was doing a poor job of demonstrating meaning to you. Why was doing what he or she was telling you to do was the right thing-the thing that’s going to help get the company to the next step? He or she was not using what I would now call leadership rule #1: lead by example.

Okay. So you’ve envisioned the times when it sucked. We’re off to a good start, because hopefully things can only look up from here. What would you have done differently if you were in your old boss’s shoes and you wanted to inspire an alternate-universe-you to do a good job? There’s probably a handful of things you can think of (and for certain people with certain bosses, maybe that handful is multiple gorilla-sized handfuls).

What if your boss, your manager, or your leader had actually sat down with you and guided you through their expectations? What if the first time through a particular task you sat together and worked through it as a team? What if there was nothing left unclear and you could truly get behind what you were being told? I’m sure you wouldn’t feel resentful of the almighty boss throwing down orders like lightning bolts from the heavens if that was the case.

But why? Here are a few reasons:

  • The clarity of expectations becomes established. There’s a lot less guessing work. Being able to establish clear expectations at work is key to building trust and having successful teams.
  • You buy in. When someone can lead by example, they’re proving to you why they value something. It’s a lot easier to get behind them compared to someone else who has never proved their knowledge, skills, or experience to you.
  • It becomes more like a peer relationship when receiving work. Initially, you feel like you’re shadowing someone that you can more easily relate to. When it comes time to take the reins, you don’t feel like you’re pulling your manager in a carriage behind you.

Emulate Ideal

As a leader, you’d be shocked if you realized just how much of an effect you have on other people. You don’t have to be the CEO or manage 100 teams of 100 people to have the influence either. The even more surprising part? A lot of your influence is actually not a conscious effort on your part. Boom.

The reason I’m suggesting that as a leader you should be emulating ideal is because people will pick up on it. People see how you act, whether good or bad, and will learn to emulate your own behavior. If you’re a hard worker who gets things done, your teammates will learn that that’s what drives the team’s success. If you’re always putting down people’s work, then it will be the norm for nobody to really have an appreciation for the work of others. If you’re watching YouTube and surfing the net all day, that’s now acceptable behavior for everyone else. Repeatedly show up late for or flake out on meetings? Don’t be surprised if meetings become less effective. Constantly encouraging people and acknowledging their successes? You’ll start to see others praising each other. These might be generalizations of course, but if everything else is aligned I’m sure you’ll see these kinds of trends.

This truly is often overlooked. Once you’ve gained respect from people and you have their attention, your actions will have a big impact. So now instead of expecting your team members to act in accordance of what you think is ideal, why not live it out yourself? They’ll automatically start making the transition, especially if you’ve clearly communicated your expectations to them.

Summary

You get the most buy in from others when you lead by example, and you’ll become much more effective as a manager or leader. You have your own expectations of what ideal is, so it’s important to communicate them with your team (Side note: expectations go both ways. Make sure your team’s expectations of an ideal leader are properly communicated to you). One of the best ways you can communicate your expectations through leading by example regularly, and you drive the point home by emulating your definition of ideal.

Extras

If you’re looking for a bit more on how and why to lead by example, consider these links:


Host Migration… Hang In There!

Well this is super embarrassing… But I had to do an emergency host migration from my Raspberry Pi to a more reliable service. It appears as though my Raspberry Pi is no longer with us. Quite a shame.

Anyway, my apologies for the downtime. Hang in there!

EDIT: Getting closer… I think all the posts are back up… New theme… I’m busy re-configuring plugins and then I have to go try and update all the missing graphics. Ugh. On the bright side, the site should be about 5x faster.

EDIT2: Just fixed up a handful of pictures. Not totally jazzed to go through them all right now, but I at least updated my popular articles. It’s definitely been a treat getting back up and running.


Innovation: Weekly Article Dump

Innovation: Weekly Article Dump (Image by http://www.sxc.hu/)

Innovation and You

There’s no denying innovation is important. You often see startups oozing with innovation completely disrupt a market and consequently, there are tons of people out there with dreams to do the same thing. How do you jack up the innovation level in your company? Why is it that startups seem to be so much better at innovating even though multi-million dollar companies have the people and financial resources to throw at R&D? Why do big companies suck at innovating?

The answer starts with your employees. Empowering your employees to innovate and embedding innovation in the work culture is key to ensuring your company continues to innovate. With big companies, the focus moves from innovation to profit maximization. Over time though, some small team of highly innovative individuals are going to find a way to do it differently or do it better, and the big players will take a hit.

Where does your company sit in the world of innovation? Does innovation come from a select few individuals?

Articles

  • Driving Innovation: This article is all about how to truly drive innovation in your company: It doesn’t come from one person, but rather many people. Arne Sorenson shares five tips for trying to drive innovation among his team members. Coincidentally, my colleague Tayfun actually wrote an innovation piece on a similar topic earlier this week.
  • Are Headphones the New Cubicle?: I thought this post by Richard Moran was pretty interesting and at least worst asking yourself the question (even if you don’t feel like reading the article). Open offices are seemingly the new way to go, but are the benefits of open offices reduced by everyone strapping headphones on? I’m personally a big fan of having an open concept office, but I do think that open communication factor is significantly hurt by having headphones on all day.
  • How to Spot a Great Leader in Four Easy Steps: James Caan says that great leaders are defined by four major things: confidence, intuition, decisiveness, and empathy. I have to agree. People need a leader they can get behind and trust to make good decisions. That leader needs to show confidence when they are making their decisions to really show that they aren’t blindly leading people down path X. However, the empathy part goes really far. After all, you’re dealing with real live people, not machines.
  • Intrapreneurship – Guest Blog by Tayfun Uzun: I’ve already briefly mentioned it here in this post, but my colleague Tayfun from Magnet Forensics wrote his perspective on intrapreneurship and how it drives innovation. It’s all about empowering each individual in the company to be innovative in their own right, and in return, the company itself experiences a boost in innovation. Check it out!
  • University of Waterloo Grad’s Journey To Becoming A Software Engineer: Here’s the part where I toot my own horn a bit. A friend of mine, Meghan Greaves, did a mini-interview with me for a TalentEgg article. It’s about how and when I knew what I wanted to do when I “grew up”, what university in Waterloo was like for me, and my transition into a development leadership role at Magnet Forensics. It was really flattering to have Meghan put this together, so please check it out and give her a shout out on twitter!
  • New Generation of Business: Connecting Employee Loyalty with Customer Loyalty: In this post by Colin Shaw, he dives into the concept of employee ambassadors and how you can build a better business by marrying employee and customer loyalty. Keeping employees engaged through your employee ambassadors will help keep the rest of your employees engaged and believing in the company’s mission.
  • Just Do it – Right from the Start!: Michael Skok provides a high-level walkthrough for startup success. The first thing? The right people. A successful company absolutely requires the right people and that’s where it starts. Keeping a solid workplace culture and empowering your employees are two fundamental things to do as you bring the right people on board. Great article!
  • Look for Advisors Who Can Teach, Not Tell: Hunter Walk shares some advice that certainly makes sense for advisory boards, but I wouldn’t limit it to just that. The idea of being able to teach and not just tell is a parallel to great leadership. Telling people what to do is not as effective as telling people what the goal is and empowering them to get there. It’s much easier to learn and grow if you’re given guidelines but you get to hold the reins.
  • Using Humor in Business: Some Practical Advice: Colin Shaw is up again this week with an article on humour in business. I think it’s pretty common that when people think of big corporations they have this vision of straight-faced people in suits carrying brief cases… but is that always the reality? Should it be the reality? Colin talks about how you can leverage humour in the workplace for things such as improving relationships or making ideas more memorable. There’s certainly a balance, but I think Colin doe sa great job explaining it.
  • The # 1 Job of a Leader Is …: If you have grammar OCD then skip to the next link right now. Fair warning! Tom Hood says that to be a true leader, you need to be doing “more better”. What does it mean? It’s simple… do better, only more! Okay, maybe it still sounds kind of strange, but the idea still applies. In order to be a real leader in your domain, you have to keep doing better. You need to innovate, push boundaries, and keep doing things better. Do better than your competitors, and do better than you did in the past.
  • 5 Lessons On How to Build High Impact Teams: Jake Wood talks about what it takes to make a high impact team. What are some of the ingredients? First, you need to know your role and how you fit in with your team. You need to embrace innovation and change. And of course, one of my favourites, “Passion trumps talent, but culture is king”.
  • Why Your Software Development Process Is Broken: In this article by Joe Emison, discusses where control in software products lies and how shifting it between developers and high-level managers can have different effects. On one hand, developers with too much control start to stick in all the fancy new technology because developers love new shiny things, and on the other hand high-level managers create a one-way flow of direction down to developers. His solution is to have a benevolent dictator that lies somewhere in the middle.

Empower your team to innovate and watch your company’s innovation as a whole increase. Remember to follow Dev Leader on social media outlets to get these updates through the week!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+

You can also check out Dev Leader on FlipBoard.


  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress