Circular Dependencies

I’ve been working with relatively green developers the past few months. I’ve been trying to find an efficient way of letting them learn from their mistakes and be creative without damaging the integrity of the product. A lot of times, questions are asked of me that I explain as best as I can on the spot. Sometimes I do a quick search on Google and find a few articles that have been better thought out than my on-the-spot explanation. The other day, a developer asked me why circular dependencies weren’t acceptable. I explained it partway, but I couldn’t find a well thought out writing piece that explained it.

How this occurs

Suppose you have a Data Access Layer (DAL) and your own logging layer for auditing purposes. Inside your DAL, you’ve got a method that is supposed to insert a record into the database. In the event that you add a record to the database, you need to log it by calling your audit logging layer. The logging layer will accept the request, and try and log it to the database using the DAL.
Now you’ve got a problem. What if the method that was initially called in the DAL is now the one that my logging layer is calling? You’re going to go around and around in a circle.

What I saw

The project I inherited has been worked on for many years by over 100 developers of different strengths in their skill set. One area that I come across frequently is how projects are referenced. Rather than adding a reference to the project itself, developers add a reference to the DLL in the Bin. Sometimes this works, other times I would have to hit Build multiple times to get a complete build. The developer was getting around the circular dependencies problem.

This can “work” based on the build order. Visual Studio helps out as best as it can, but it cannot help out with references to DLLs directly. Projects references need to be added correctly for Visual Studio to help you.

How do you solve this problem?

The example above will never end. It violates the Single Responsibility Principle. The Single Responsibility Principle states that each object will be responsible for only one purpose. There should be only one reason to change the class. While I try not to go overboard with SOLID design, this is an example where you have two different layers that need to be called by a middleman.
Create a layer that calls the DAL directly. In this newly created layer, also call the logging. This prevents you from creating a circular dependency.

Each object now will follow the Single Responsibility Principle. The DAL only puts things into the database. The DAL does not care about logging, who is calling it, or what happens next. The Logging Layer will allow for other middlemen to call it, and it will behave the same way. It can log using the DAL if it wants, or it can call a web service, or log to the file system. Finally, the middle man is responsible for making sure that both the DAL and the logging are called. The middle man is responsible for the order of execution, but it does not care how either the DAL or logging occurs, just that it occurs. Each layer only has one reason to change.

E-mail - The Friend of this Developer

Ed Wisniowski wrote a post called E-mail – the Enemy of a Scrum Master. He calls e-mail a time suck of busy work, and a poor way of conveying information to others. He makes some valid points about e-mail and how it is abused. Ed and I work together, and work together well. He and I are often receiving a lot of the same e-mails and included on the same exact chains.

I’ve seen lots of different tools tried to be used, some come and go. Others stick around longer and make traction with certain teams and that’s great. But it is specific to that team and everyone has to be involved in it and learn it. It doesn’t matter if they’re using webmail, Gmail, Outlook, Thunderbird, a Mac, or a cell phone . Everyone has an e-mail– it is the first thing that people get when they go to an organization. I had an e-mail at my current company before I had a computer!

What I’ve discovered as a developer is that e-mail is my favorite collaboration tool. Screen sharing is great, but there’s always problem with people not really paying attention, having connection issues, and being there. Trello is certainly popular, but it requires people to learn to use it, discussions about how to use it, and so on. Instant messenger is great, but then there’s different networks, versions, requiring the user to be there, and so on. E-mail on the other hand – everyone knows how to use it, e-mail isn’t dependent upon any software, and it doesn’t require both parties to be available.

But perhaps the best part of e-mail is when it requires my attention – on my time. Ed can send me an e-mail asking me for a status update, notify me that he is requiring a report for an upcoming meeting, or anything else and I don’t get interrupted. Writing software is tedious and requires undivided attention to write it efficiently. I turn off e-mail notifications because I don’t want to be interrupted. I do the same with instant messages. Every interruption anyone receives, including scrum masters, delays that task from getting done. Developer or not, flow is the hardest thing to find in the work place and it should not be destroyed.

Ed quotes the agile manifesto saying that face-to-face conversation is the most efficient way of conveying information. This is somewhat true- face to face communication is the most efficient way of getting information to people. If I’m working with a developer and we are speaking, having a hard time conveying information to each other, we can walk to a white board, sit down at a machine and look at something, look at documentation, etc. This requires developers to be in the same location. This can be a problem when half of your team is on the other side of the world. It can also be difficult because one of the parties may be elsewhere physically (like in a meeting) or mentally. Additionally, if there is something that is forgotten, or not clear, another instance of communication needs to happen again. This frequently happens with problem solving. With an e-mail, the communication is there in black and white for reference to at any time in the future.

Ed gets at least 3 times the number of e-mails I do. This comes from his role on the team, and the number of teams he's on. I frequently unsubscribe from automated e-mails. I have told people to not include me in certain subjects unless necessary. I decline meeting invites if I’m not needed. I recognize Ed’s problem of e-mail abuse and deal with it as best as I can.

E-mail needs to be used efficiently. Specific subject lines, bullet points and bold text are all great ways of making your e-mail efficient. The first lines of most of my e-mails frequently indicate what I’m trying to do and the problem I am encountering. Long e-mails are frequently ignored by readers, same thing with frequent or automated e-mails.

It takes time to develop the skill of managing e-mail, and communicating efficiently in them. I find myself taking an extra minute or two with writing and reading e-mails so that I do not waste others’ time.  Our job isn’t to communicate about software development, it is to develop the software. Communication just helps us write the software as a team.