Monday, March 28, 2016

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.

Sunday, March 20, 2016

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.

Friday, March 13, 2015

Six Things That Make Scrum Great

I wrote a post about how there are many things I don’t like about scrum.  But I do like scrum in general. There are parts that I may not like about it, but nothing is ever going to be perfect. I’ve seen a few different approaches to scrum, and it has evolved since I first started doing it seven years ago.

Scrum is a framework intended to help prioritize tasks and improve teamwork. Through communication, better estimations, and feedback, the process of completing tasks is supposed to move quicker as time goes on. Scrum is used primarily in the software development world, but I’ve had it applied in the accounting and marketing departments. There are also stories of many other projects that are not software based that have had scrum applied.

Scrum is easy to understand

Even if you’re not familiar with the scrum process, or you’re new to it, you can contribute and understand what is going on. With a little bit of training, you can understand the roles and expectations everyone involved. Take a look at a chart, the task board, or attend a stand-up and you can get a good idea of what is going on.

Break downs

By going through the planning of a story, I believe you’re actually starting your work! I’ve always been a big fan of planning. In college, I had to account for nearly every minute of my time a week in advance so I could make sure I knew what I could accomplish. When you task out a story, you’re breaking the story down. You’re making a plan, and the team can say, “You’re on the right track!”
I like seeing things organized in a way that I can categorize them. The smaller the compartment, the easier it is for me to understand and accomplish. It helps prevent me from getting overwhelmed which I have done so often in the past.

Task Boards

Physical task boards are the best! When I’ve seen the task board at its most effectiveness was when each person had their own color post-it and had to get up and physically move the post it to the done column. There is something in your mind that makes you feel good when you physically can move something. However, now I always work on a team where we need a virtual task board. On the surface, it serves the same purpose but I don’t find it as satisfying.

The task board allows anyone walking by to silently take a glance and answer the question of “What is the status?” I hate that question. The task board will tell anyone exactly where developers are at and you don’t need to interrupt.

Stand Ups

I can get caught up in my own world. I can get so focused on a story that I lose sight of what the rest of the team is working on or struggling with. When I am operating at my best, my headphones are on, and I will forget that I’m around others. This means I don’t interact with anyone. I prefer it this way.

Stand ups force me to look at people, gather around the task board and listen to everyone speak. They can ask me a question, or I can help them out if I see something going on. The best part is that it is limited to 15 minutes! Of course something can come up that isn’t stand up appropriate and we would talk right after.


I like looking at projections. I like knowing, “On February 28th, we should be done with our project. It becomes a competition for me because I want to then say, “Ok, let’s see if I can finish by the 21st.” It becomes an interesting game for me. This creates an internal challenge.

Projections also allow management to plan around the development team. I have yet to see a better way of setting up projections in software development.  If the product owner wants tax calculators to be done by April 15th, set the priorities, do some averages, draw some lines and you should be done.

You even have projections in just an individual sprint. “Can I earn myself an extra day of training by finishing early? Let’s try.” Projections tell you when there are problems, or when things are going well. As long as your team is honest, and thorough with their estimations, there can be a lot of great things to be done with the projections one can generate from the scrum process.

Faster Turn around

When you can deliver part of the software, you should deliver it. You’re going to get reports of inefficiencies, or bugs in this process sooner. The sooner you get feedback, the easier it is to make adjustments. From a development standpoint, this is ideal. There is nothing more frustrating than finding out that you built features based on a misunderstanding.

Clients are also happier because they get to see their product sooner. They’re spending resources and they finally get to see what they’re spending money and time on. Compare that to waterfall, where there is a big bill and they don’t see anything for a long period of time. Usually waterfall involves a dispute at the end as well.

My favorite parts of scrum involve transparency. The organization is there for everybody to contribute to and observe. There are bunch of great things about scrum. These are just a few of my favorite things that I like to take advantage of.

Friday, February 27, 2015

Scrum is great, but...

I like scrum. The ability to shift direction of the product relatively quickly is valuable. I think there is a lot of merit to the idea of a product that is shipped regularly. Perhaps the biggest advantage of scrum is the early feedback. Nothing is worse than getting something, and realizing it isn’t exactly how you wanted it to be.

In the past few months I’ve spent a lot of time looking and analyzing the scrum process, gone through some formal training, talked to a couple of experts and come up with my own opinions. Some do show the weaknesses in scrum, and some may be just flat out disagreements with the scrum process.

All team members are not equal. 

Scrum is built on the idea that all team members are passionate about the project, and respect each other. A cross functional team is a great idea where we can help each other out when appropriate. But that’s not always the case. The truth is I’m not a BA expert. Can I do it? Sure, but I’m significantly less efficient at those tasks than I am when I’m coding. Not everyone has experience doing QA. At my place of work, I don’t even have the tools installed on my machine for design. So there’s a role/specialization in development that says not all team members are equal, and they shouldn’t be!

Additionally, team members have different levels of dedication. A disgruntled, jaded employee is going to have a different level of dedication than the new guy looking to make an impact. Their goals at the company are different. Some want to ship software, some want to improve their skill, and some want to just collect a paycheck. The idea is to hire motivated employees, but let’s be real – you cannot keep everyone happy, motivated, and having the same goal.

Self-Organizing is great but… 

Scrum is supposed to allow teams to self-organize. However, it treads a dangerous line in a lot of areas. It is our nature that when five people get together to work towards a goal, that someone acts in some sort of leadership role – even if it is an unofficial one. This is the self-organization. But that conflicts with the all team members are equal. By placing leadership on a team member, that’s no longer equality. Additionally, you tend to let people who are more aggressive and outspoken dominate the conversation, potentially not knowing about the project.

For example, I once was working on a complex engine for an application that I worked on. Three developers huddled around the whiteboard and talked about potential issues that could come about. Two of us were working together, and making good progress. The third was not. The third developer was new to the organization and didn’t have knowledge of the business rules. However, because he had the type of personality to dominate the conversation it stopped progress. He should have been asking why instead of dictating. Fresh views are great, but the personality can be a problem.

Third Parties 

I always seem to work on projects that have heavy third party integration. Any time you work with a third party, you inherit their headaches times ten. You cannot do anything about them, you can only prepare for them.

For example, I had once developed a feature on an application based on insurance risks and rates. The rates would come from a third party. Before actual coding had started, the contracts were written and agreed upon. The third party told me that the service I would need to call would be available in three weeks. I had mocked up a service that I could control and develop against. Not the most efficient way of developing, but it works. Once I finished up my side of the development, I really needed to test with the third party, who was now multiple weeks late. Like any waterfall project, when one module is late, it pushes the next module to be late. This delayed the release. Eventually they finished with a completely different contract that we agreed upon. You can try to protect yourself from third parties, but I find that they always find a way to disrupt your schedule.

Bugs have no real plan 

Scrum seems to be ideal for a new project that is starting from scratch. You don’t have to worry about legacy code, being pulled into other projects, or bugs. Let’s face it – every developer who isn’t Larry Gasik has bugs in their code. I have yet to see anyone implement a smooth plan allowing for when things come up. I’ve seen different approaches to handling bugs, and I don’t like any of them. Reduced capacity makes planning look bad and encourages lazy developers. Swapping stories in a sprint destroys morale and timelines.

Shared Resources

Smaller organizations allow people to wear multiple hats. This can be both beneficial and detrimental. In large organizations there are almost always too many hats. This is a major problem. Depending on the project, a scrum team may not need a full time DBA, a UX expert, a front end coder, etc. These types of resources then get shared among the organization. When this happens, you’re adding another hurdle for the development team to complete their job. This goes back to a scrum team relying upon third parties. When these things happen, your projections can change based on that third party. When that third party has their own sprint or schedule, it becomes difficult to interact with them and get things done in a timely fashion.

Scrum is great but…

It is a framework. It is not intended to be followed by the book. Modify it to be what works for your needs. I’ve never had a full time product owner. I feel like I’m going to find a unicorn before I locate a full time product owner. On a project with only three people, I’ve had to be the scrum master and developer, and when that happened, it was more successful than just complaining.

Too often I am seeing scrum being hailed as a silver bullet, and that any time scrum isn’t working for a project, it is because the process isn’t being followed. The scrum framework is built upon ideals when in reality you may not have the set up that scrum thrives in.

Sunday, May 18, 2014

Mythical Man-Month Chapters 1-5

I started reading The Mythical Man-Month by Fredrick Brooks– a near 40 year old book about software development teams and timelines. The underlying idea is that you cannot just throw workers at a project and expect results. I heard about this book a while ago, but I couldn’t ever track it down at a library, nor could I find someone who would let me borrow it and to be honest, I didn’t want to pay for it. Just recently I found someone who would loan it to me. The book is old, and there are some parts in it that help show its age, but the underlying concepts are there and go into more thought than I’ve ever had about them.

While I’m only a few chapters in, as a developer, it has been quite depressing for me. There’s a section where it talks about the productivity of developers, and brought their salary into play. The developer who makes twice as much as the other is not twice as productive. The developer at twice the salary may be ten times as productive!

It is an interesting time for me to go through this book. I’ve been at my current workplace for just over a year, and I’ve been with my project since its beginning. I’ve seen developers come and go on the project. Team leads, and project managers moved around. At one point, we had 11 workers on the project full time, and in less than a week the team will have six. The number fluctuates, and the team looks very different than when we first started.

For the most part, the team has worked well together. I believe that is because of each individual’s ego is inline. Mythical Man-Month compares development teams to surgical teams. Each person in a surgical team has a specific task. One person may be deciding how to split away something, another person may be splitting that into smaller more manageable tasks. Another could be actually doing those tasks. Then there are the individuals who are helping support those actually building, such as secretaries, and managers who will be gathering information from your client. This works because everyone knows their role, and follows it.

So why did the beginning of Mythical Man-Month depress me? Because I’m seeing the concepts in the book come into play and be accurate. Developers are optimists, and they’re horrible at estimating. The money wasted on bringing new people on board only to see them go has costs go through the roof without positive impacts on the team. Furthermore, I am now thinking about if I am as good of a team member as I had thought, my place on the team, and what I’ve been doing to improve it.

It also depresses me a bit because of the approach to software design, and how ends up in the end user’s hands. For example, our product owner will request some report. The team will gather information on said report, by asking questions, doing some database research and basic proposals. Everyone will agree that this report is important and it needs to be generated a certain way. While in the middle of actually building it, suddenly the requirements will change. For me that is extremely depressing. I feel that it shows a lack of planning and respect for the developers’ time. Mythical Man-Month touches on a related topic when it goes into talking about focus and effort. A feature that may be used once a quarter can take a long time to build. What if those efforts went into something used every day? I’ve seen problems like this throughout my career, and it makes me stop and wonder about where my energy should be placed.

Thursday, May 15, 2014

Scrum: A Breathtakingly Brief and Agile Introduction

I’ve been on a handful of scrum teams. I understand scrum and I like scrum. I’m not going to go into the strengths of scrum, or the negative points (unless painfully obvious in the book) of scrum. I’ve done other agile types of development, but scrum seems to be the strongest for the corporate world in my opinion.  With that said, I’ve never been on any team that fully follows scrum. There’s always subtle variations to it that the team needs. The basic ideas are the same though.

The book is short, and you can read it in a half hour. I think it is a great introduction to scrum, and some of the basic goals from all points of view. I would recommend this to anyone who has not been doing scrum, or wants to know more about it. If you’ve done it on a couple of teams, there will be nothing new for you.

The book starts out talking about the types of team members. There are three – the Product Owner, Scrum Master and Team Member. The one I found interesting and I think needs to be addressed is the Team Member. Team Members need to be cross functional in my opinion. The book talks about specialization but later retracts it a bit.

  • “People who do the work are the highest authorities on how it should be done.” This to me brings to light one of the biggest downfalls of scrum, and that is poor architecture is often a result of scrum. When a developer has a misunderstanding of the ultimate goal, or different point of view, this can lead to poor decisions with architecture. You also must remember that not all developers are strong in the architecture area
  • Doing my job vs. Doing the Job – The ultimate statement of being cross functional. It doesn’t mean you have to be an expert in all areas of technology of the product, but you need to be able to do it.

This goes back to my cross functional team members. I believe that scrum is under the fundamental understanding that nearly everything is able to be completed by any team member. Sure there may be a few things that are an exception, and not everyone will be on the same level, but everyone needs to act on the best interest of the team.

The book brings up burn down charts. Burn down charts are awful any time the scope changes. For example, if my product owner comes to me and adds 6 hours of work to the sprint, and I complete 8 hours of work the same day, according to the burn down, it looks like I only did two hours of work. Additionally, you show me a release burn down where there isn’t a story added. When a story is removed (say it is no longer necessary) it looks as if the team did a great job! I much prefer the idea of a burn up chart.

Meetings vs. Ceremonies – I forgot about the “ceremonies” title. At first, a major selling point of scrum and agile was less meetings. I was sick of having meetings every other day to discuss status on work. Those meetings were an hour or longer. With scrum you have more frequent, but shorter meetings. Probably a wash in reality.

Sprint Planning – I’ve never done scrum with a full time product owner. Having a dedicated resource to be a product owner is expensive. As a result, I’m reminded that I’ve never done sprint planning as efficiently as it could go. The book divides sprint planning into two parts that I don’t necessarily agree with, but I understand what they were going for.

  • Part 1 (What will we do.) – The product owner decides what stories will be considered for the sprint. To me, this is pointless. The point of the prioritized backlog is the indicator of what should be done. This step only exists because product owners do not keep the backlog up to date.
  • Part 2 (How we will do it.) – The team breaks up these stories and tasks them out. The product owner is available for questions on how to do this. I’ve never had a product owner regularly available during sprint planning. As a result, I believe developers need to groom the stories early to help understand the stories. This will not occur during any “sprint ceremony”, but needs to be a regular occurrence. This will also help understand the end goal of the system. The problem with my preference is that it does take a lot of time.

These are based on my experiences and opinions of scrum. Like I said earlier, every scrum team has their own obstacles that won’t work in the textbook definition of scrum. Scrum is about small teams. And if you don’t have a small cross functional team that can be trusted, you’re in for trouble down the road.

Monday, April 1, 2013

Async and Parallel Programming in .NET 4

I spent some time recently on some of the latest features of .Net. One area I overlooked a while back was Async and parallel programming. I've done mostly web development and it hasn't always been beneficial to me. Lately I've expanded my talents, and this has come into play.

Essentially the Task Parallel Library (TPL) helps add parallelism to your application without having to worry too much about your thread pool or exceptions. You have to worry about these things, but the TPL has really helped out in the simplification of these areas. This is important because as technology advances, our applications need to be more snappy. For example, on the Windows Store applications, you may have multiple threads happening, but you cannot lose responsiveness to your application. Microsoft will reject your application if it does not respond.

Tasks are the fundamental building block. I think of tasks as function that will consume a large number of CPU cycles or require information from a third party. If we had a single threaded application, we'll be forced to wait for these functions to complete. However, we can create a task that will start up another thread and we can go on our doing other things.

As always with multi threading, there is additional complexity versus having a single threaded application. The TPL helps handle these issues. Each task will have a status, a result, and an exception that can be checked for processing. How variables are passed into tasks will impact your results. The order of execution can also be impacted because of multiple threads running at the same time. The TPL helps you handle it all.

I'm going to spend some time focusing on a few different areas of the TPL and show how they may be able to help you out in development.