Tag: delegation

Failure – Weekly Article Dump

Failure: Weekly Article Dump (Image provided by http://www.stockfreeimages.com/)

Failure: Should You Fear It?

Thanks for checking out this weekly article dump, and sorry it didn’t make it out on Friday. I was out visiting family in Alberta and I didn’t have enough time to get this post all set up. Better late than never!

The theme for this past week seemed to be articles about failure. Not all of them, of course, but a lot of authors are writing about what it means to fail and why that’s not always such a bad thing. Do we need to avoid all failures in order to be successful?

Articles

  • Stepping Away, So Others Can Step Up: In this article, Jonathan Bush┬ádiscusses something that’s often hard for leaders to do… Step away. It’s difficult for many people to disconnect and have trust in their team to get things done. Trust should be at the center of any highly functional team. At Magnet Forensics, we embrace trust as our core value because we know we’re working with talented people we can rely on. It’s crucial for ensuring that people can operate effectively to the best of their ability.
  • HELP! I Hired the Wrong Guy: In this article, an individual has written in and gets some advice on how to handle a bad hire. Liz Ryan┬ámakes some great points on how to address the issue, including a nice segue for the person that wasn’t such a great fit. This first example of “failure” to hire properly offers a lot of learning. Know what warning signs you ignored this time around. Know how you can detect it before the hire happens and worse case, how you can detect a bad fit early on.
  • Negotiate Great Deals, Without a Fight: Firstly, I’m sharing this not because it might be a good sales tactic or business tactic in the perspective of making money. Forget that for now. In my opinion, this is a great tactic for you to take when you’re trying to pitch your idea. Next time you’re working in your team and analyzing the pros and cons of some decision, remember that you’re not out to make your opinion the only one and everyone else a loser in the outcome. Fight for the win-win, which is often a combination of multiple perspectives. Great article, Joel Peterson.
  • Why We Should All Embrace the F-Word (Failure): Arguably the article with the most eye-catching title this time around, Amy Chen┬ádiscusses failure and why so many people fear it.
  • Vulnerability Makes You a Better Leader: This article by Brad Smith discusses why a perfect leader is actually less than ideal. In order to make people really look up to you, it’s important to show them that what you’re modelling is attainable for them. Chasing perfection isn’t realistic, but chasing awesome certainly is.
  • 7 Signs You’re Working in a Toxic Office: Definitely one of my favourites this week, this article addresses some key signs that your place of work is a crappy place to work, from a work culture perspective. Not only that, the author discusses how to go about solving the problem if you’re the victim or if you’re the perpetrator! Great stuff.
  • Don’t Write Off the Coaching Leadership Style: Daniel Goleman discusses why leaders that act as coaches shouldn’t be forgotten. A leader that can coach is familiar with their teammates’ individual strengths and weaknesses. This let’s them delegate effectively and help address the weak areas of their team.

Hope you enjoyed, and remember that failure isn’t always a bad thing! Remember to follow on popular social media outlets to get these updates through the week!

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


Example: Getting Data Back From An EventHandler

Background

I previously wrote about why I like to use events here and here. I figured it would be appropriate to illustrate a simple case where you can delegate decisions between functionally separate parts of code (say, between an application layer and a presentation layer). If you’re well versed in C# and .NET, this might put you to sleep. If you have no idea what I’m talking about, hopefully this will help. By the end of this, hopefully you’ll have a better idea for how you can use an EventHandler to pass data/state back through an invoked event… And don’t forget to check out the code!

The Scenario

Let’s assume we have a layered application, which is usually my go to. I might have three layers: one for data persistence, one for my business logic and one for interacting with the user. I’ll call these the data, application, and presentation layers, respectively. Let’s also assume that the dependency flow works from the top layer down (so presentation layer depends on application and data, and application depends on data). Nice.

In my application layer, I have a class that can process data. Specifically, it can capitalize an input string and spit out the capitalized output. However, some input characters are not letters A-Z or a-z… So how should our processor behave? Let’s have it delegate this decision to the user (who interacts with the presentation layer) and get back our result.

The Workflow

The following is the workflow for the application:

  • Create a processor object
  • Hook on the event handler so that the presentation layer can handle the corresponding event
  • Start processing the input
  • Capitalize valid characters
  • When we reach an invalid character…
    • Call our data processor’s event to delegate the work to anyone who can make the decision for us (in this case, our presentation layer)
    • Have the event handler (the presentation layer) ask the user if we should skip the input
    • Store the result back on the event args
    • Back in the processor class, based on the result of the event args, we can skip or add the character.

 

Summary

It’s a pretty straight forward task really. Because event args are objects in C#, we can store state on them and pass them around easily. If they were value types, we’d have to rely on function calls to return the user’s decision as to whether or not we should skip the input. In my opinion, this is a bit uglier (but certainly still doable).

I’ve created a sample project and hosted it at Google Code, here. Check it out!


Why Events? Decoupling.

Background

Previously, I wrote about how events provide you with flexibility in your code. If you take on an event-based paradigm, you can view your system as a group of components that have events execute when certain conditions are met, and less of a procedural view where X always must occur after Y. But what else do events let us do? Decouple your architecture! We all know decoupling is a beautiful thing, so let’s see how it’s done.

 

How Events Decouple Your Code

So the big question then is, how? I’d like to start by providing framing an example architecture. If we assume that we have code that is decoupled by major functionality, we might have some sort of layered architecture. This could mean that we have three layers: presentation, application, and data. These layers would be responsible for user interaction, core business logic, and data storage/retrieval respectively. Let us also assume that the knowledge of layers flows from the top down. In our example, the data layer knows only of itself, the application layer knows about itself and the data layer, and the presentation layer has access to all three. It’s essentially just the flow of dependencies. Great. So where is this going?

If you’ve structured the various components in your system to take advantage of events, C# events provide us with a pretty awesome signature: you get the sender of the event, and a little magical parcel of data called EventArgs. Now let’s recall that in my previous posting, I mention that an event is really just a type of delegate. What does it mean to delegate? Literally, what does it mean? The great Google tells me: “Entrust (a task or responsibility) to another person, typically one who is less senior than oneself”. There. The secret of decoupling. My code can’t take responsibility for doing something, so I should tell whoever is interested that now might be a great time to do something.

 

Let’s See An Example!

Let’s continue off of the sample architecture that I already started off with. So we have our three layers. Let’s pretend we have some sort of import process where we read in lines of a file. Every line in the file is supposed to have two values, separated by a comma. This is all done by an importer class in our data later. Sounds easy.

Now, I’m not suggesting this is something you’d actually want in your application, it’s simply to demonstrate my point. So let’s pretend that the source of our data could sometimes be poorly formatted. Our import function can easily know about this (i.e. it splits the line on a comma, and finds out that there are not exactly two values). But does it know how to resolve it? Is it supposed to skip it? Is it supposed to magically figure out how fix it? Does it crash and burn? Wait… Maybe it’s not responsible for making that decision… So who is?

Invoke that event! If your importer class has an event, let’s say, LineFormatError, then someone on the outside can subscribe to it. Maybe my presentation layer can subscribe to it and, through event args, tell the invoker of the event (my importer class reference, of course) how to handle it. The flow could look something like this:

  1. Hook your necessary events up, so something in the presentation layer hooks on to my importer’s event for line format errors.
  2. Start your import.
  3. Upon hitting a poorly formatted line, invoke the LineFormatError event.
  4. The presentation layer receives the event (so now we’re in the “event handler”).
  5. The presentation layer could use information provided in the event args to ask the user if they want to skip the line.
  6. Based on the user’s decision, the presentation layer sets some information on the event arguments that says whether or not to skip it.
  7. The control goes back to the data layer where it checks the event args for what to do–skip or abort.
How is this decoupled? Well, quite simply, you don’t have your data layer directly showing message boxes to the user to decide what to do. It has absolutely no idea that there’s even a message box being shown… it doesn’t care! It simply agrees that it’s not responsible for making the decision of whether or not to skip or abort, but let’s someone else handle it. It delegates the decision through an event.

 

Summary

Events are beautiful things. Leverage them, and you can take advantage of some really decoupled code. Your various components often can’t be responsible for certain tasks, but using events, these components can delegate the decisions to other parts of your code that are certainly responsible for making the decision.


  • 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