The Dependency Inversion Principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

(Source WikiPedia).

Throw that at a terrible programmer, and all you’ll get is a terrible programmer that is annoyed and hates you. So true!

Take the following method:

        public void PrintHelloMessage()

        {

            Console.WriteLine("Hello");

        }

Now ask a developer to add a new method to print the message ‘Goodbye’. Do you think he would do:

        public void PrintGoodbyeMessage()
{
Console.WriteLine("Goodbye");
}

or:

public void PrintMessage(string message)

{
Console.WriteLine(message);
}

Most likely, he’d do the latter. Why? Because he realizes he’s gaining a benefit by passing a parameter to a method. He knows that if tomorrow you ask him for a “Good Afternoon” message, he won’t have to write a new method.

What is Dependency Injection? It’s one way of complying with the Dependency Inversion Principle. However, when you think about it, what does it boil down to? Passing a parameter to a method, which happens to be a constructor. It seems simple enough doesn’t it? Yet, it’s hard for people to understand it. Why? because they don’t see the value in it.

Explaining a principle to someone without them understanding the benefits and values they get out of it is useless, and that is why concepts such as Dependency Injection or Inversion of Control seem overly complex to the vast majority of developers (believe it or not, those of us that use these things are still a very big minority). It’s complex because they haven’t been explained the values of it. They’ve just been thrown some definition and they are expected to understand that it’s bad for one class to create an instance of another class it uses.

Present a developer with the following code:

    public class AuthServices

    {

        public void AuthUser(string username, string password)

        {

            var authDAL = new AuthDAL();

            var user = authDAL.GetUserByUsername(username);

            if (user != null)

            {

                if ...

            }

        }

    }

and ask them how they’d go about testing this code without having access to a database. Ask them how they’d go about changing AuthDAL for some fake DAL that doesn’t really connect to a database.

They’ll probably come up with the solution of passing the AuthDAL class in as a parameter, and eventually realizing that multiple methods will use the same class, they’ll pass it in via the constructor and set it as an instance field. As long as their AuthDAL has virtual methods, they can create any fake DAL that overrides those methods and returns some dummy value. They might argue that they don’t want virtual methods. And that’s fine. Tell them to define the parameter as an interface. In fact, they probably have already heard of a principle that says that you should program to an interface and not a class. They’ll eventually end up with this code:

  public class AuthServices
{
IAuthDAL authDAL;
public AuthServices(IAuthDAL authDAL)
{
_authDAL = authDAL;
}
public void AuthUser(string username, string password)
{
var user = _authDAL.GetUserByUsername(username);
if (user != null)
{
if ...
}
}
}

And voila! You have Dependency Injection via Constructor.

Once they *get* that, then explain to them other benefits, you know the real benefits they get from doing this: decoupled code, easy maintenance, promotion of SRP, etc.  and then throw the principle in their face:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

And they’ll see how it all makes sense.

It’s not about throwing or not throwing books. It’s about showing people how something can help them, how they get value of it.

We’re all busy these days and sometimes it’s really hard to get any work done with continuous interruptions. As developers we know that it’s hard to get into the mindset that allows us to concentrate on designing a certain class or fixing that retched bug, and any minor incident can throw us way off and place us back at the starting line.

Now I’m sure that it’s not only developers that have this problem. Any type of work the requires concentration probably has the same issues. It just so happens that most of my life has been spent developing software and I speak from experience. Getting interrupted while working on code is a pain!

Avoiding Interruptions

Interruptions can come in the form of emails, telephone calls, instant messaging and recently the more popular Twittering, which I’m finding is substantially limiting my ability to both read or write more than 140 characters. In fact, I’ve written this post via a Windows Live Writer plug-in that injects 140 chars at a time.

There are several ways to cope with this problem. For example when using Outlook, you can suspend the Send/Receive for certain periods of time, or just do what I do and shutdown the damn thing, as much the same with Twitter, Skype, etc. I assign myself periods of a minimum of one hour where I just code, and not deal with email, messages or Twitter. I then take a 5-15 minute break, check all correspondence and go back what I was doing. I find it helps me be much more productive. Other people use techniques such as the Pomodoro or Pair Programming, which personally I find very productive on many levels, but in terms of interruptions. While sitting with someone, it feels kind of wrong to be chatting on Skype or replying to emails while making your coding partner wait. As such, you tend to not do it so often, and avoid potentially embarrassing situations

Avoid causing bottlenecks for others

Increasing productivity is one of the major benefits of avoiding disruptions. Like anything however, there’s always two sides to every story.

Whether working on a team or solo, you tend to interact with people, be it a team member, someone else in your company, customers or 3rd parties you deal with. These interactions are mostly based on emails, IMS’s or phone calls, you know. the same things that disrupt our productivity. Now it’s great for you to be able to control them to increase your throughput, but you need to also bear in mind that what you’re doing is potentially holding up someone else’s productivity.

If someone sends you an email to ask for information about a certain project, or how something should be done or who to contact for a particular thing, these issues might not be effecting your job directly, but most likely it is interrupting theirs.

That is why it’s important to remember that when responding to someone, especially with emails where there is an inherent delay, to always take into account how important the reply is for them, more than for yourself. Does it hold them up? Is it a potential issue?

Obviously sometimes a response requires a little more work, but it’s also very important to communicate this to the originator. Tell them that you need 2 hours to get back to them and you can’t fit it in for another 2 days. The important thing is to not leave people hanging.

Remember, what’s not important for you, might be critical for others. Sometimes I miss the Urgent flag in Gmail. It’s utterly useless for SMTP servers, but it does communicate intent to the receiver of the mail (albeit abused by many).

As if what Alt.NET is or isn't, whether it's mean or not, wasn't enough, now we have a new guy on the scene, and already the first reactions on the blogsphere (not to mention mailing lists and twitter world).

Well before I give you my opinion, let me ask a couple of questions:

Have you always written applications that have been bug free?

Have you always written applications that were a breeze to change and changes would not introduce new bugs?

Have you always written applications were the code was easy to understand after not looking at it for 6 months or for a newcomer to the team?

I haven't. I've worked on applications were I used to not sleep a day before a new deployment, not knowing whether those last minute changes broke something. I've picked up applications that took me weeks to figure out. I've been on projects of 7+ people were the bus number has been as low as 1, both as a developer and as a stake holder. I've learnt from my errors and I am continuously trying to improve the way I develop software to avoid making the same mistakes I've made in the past.

Unit testing, Test Driven Development, Dependency Inversion, Single Responsibility aren't required to make your software work. You don't need them to deliver applications. Your applications will still work without them. You can still link business logic to partial classes of datasets or hook them up directly to code-behind files in your ASPX pages. You can still use databinding with ObjectDataSources and your application will still work. You can still ship software that will work well for millions of hours with hundreds of thousands of users connected to it.

However, I'm quite certain that you'll suffer the consequences. I'm pretty sure, having been on both sides of the fence, that it will be easier to make a change to an application where you have a clear separation of concerns as opposed to the drag-and-drop version. It will be more re-assuring to make a change and have 90% of your unit tests pass, fix the remaining 10% and then deploy, as opposed to just ship and hope for the best.

That's why I write unit tests, to try and catch as many bugs that I introduce when making changes to existing software. That's why I apply principles such as SOLID, to make my code easier to change and more understandable

Alt.Net or the recent manifesto of Software Craftsmanship for me represent ways to improve my job and myself. Ways to develop software that will make it easier for me. At the end of the day, what I care about is what I'm responsible for, and that is myself, my team and the software I write. It's not about making a statement or trying to change the world. Another matter is if I choose to share my experiences with others, which I'm free to do. But it's not about forcing one way over the other.

Maybe the ways that I've learnt to improve up to now are not entirely correct. Maybe tomorrow we'll find better ways to write software, to make our life easier. However, I know that what I'm doing today is better than what I did yesterday. But that can only be accomplished if I'm willing to accept that I don't know it all and I'm open to improvement.

I was just reading the transcript from the StackOverflow podcast nº 38. I came across it via a post from Jeremy Miller’s blog, since I normally don’t listen (actually I’ve never listened) to the StackOverlow podcast. Well it seems that there’s been some comments regarding this particular podcast, since Jeff Attwood, of Coding Horror fame made some comments about not caring about quality. No doubt I disagree, but this particular post is my beef with some of the other things mentioned in this podcast.

I don’t know how long Jeff or Joel have been programming, and to be frank I don’t care. I do know how long I’ve been at it. I’m not going to bore you with the details, but suffice to say that it’s been long enough and I’ve made some terrible mistakes and suffered the consequences while writing code and managing teams. We all live and learn, and one of the best ways to learn is from making mistakes. What I do care about however, (care maybe too strong of word, maybe "bothers me" is better) is people talking about things without proper knowledge.

Joel starts talking about Test Driven Development and 100% test coverage, which is not correct, and says:

…breaks 10% of your unit tests. Intentionally. Because you’ve changed the design of something… you’ve moved a menu, and now everything that relied on that menu being there… the menu is now elsewhere. And so all those tests now break.

Now I’m not even going to question what a menu position is doing in a unit test, but normally if you design your tests correctly, if something breaks it means it’s broken. It means the change has caused a test to break, and that is a GOOD thing. If your tests are breaking when they shouldn’t then your tests are maybe wrong. If you have to update the tests so they pass, then you’ve most likely changed the design, but you’re explicitly acknowledging this.

He then goes on to talk more about unit tests:

make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.

I’m curious how benefit is actually being measured here, not to say that the statement is an oxymoron if your tests serve their purpose.

The next part I’m perplexed with:

Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (That’s a real easy-to-Google term!) It’s object-oriented design, and they’re calling it agile design, which it really, really isn’t. It’s principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.

I’m all against acronyms, but please understand things before making statements about it. Nothing in SOLID is bureaucratic. And to say that people that apply SOLID have not written a lot of code, frankly, is just plain bullsh*t. I would say quite the contrary. I would say that people that have written a lot of code, know the side-effects of introducing changes, and how things can blow up in a million places, understand how code without tests can make your life miserable, how you worry about every other deployment you make because you don’t know if the changes you made have broken the estimate calculations, or whether negative values can still be invoiced correctly, these are all things that make you appreciate more principles such as Single Responsibility or Open-Closed Principle.

Joel then goes on to talk about interfaces:

So, you’ve got some class, with 40 different little methods on it, and I’m only going to use six of them, so I should make an interface with those six things that I can use, and the class will implement that interface, and that’s my contract with the class, that those are the only six things I’m going to use.

Is it only me that thinks this whole paragraph is nonsense? Have you completely missed the point of what an interface is Joel?

And then we come across the fileophobia:

Because what they’re doing is spending an enormous amount of time writing a lot of extra code, a lot of verbiage, a lot of files, and a million little classes that don’t do anything and thousands of little

I’ve said it a million teams: you’ll have other sh*t to worry if you ever hit the NTFS file limit per directory.

Continuing:

This seems to be where a lot of the Object Oriented Design community went, and if anybody has any strong feelings about this, call in and tell me what you think–tell me if I’m totally off track here–but it seems to me like a lot of the Object Oriented Design principles you’re hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture’s sake.

Joel, I’d love to come on your show and tell you you’re completely off track but I’m sure there’s tons of other people more qualified than me that can do the same. This is not about architecture for architecture sakes. This is about not developing DemoWare applications that blow up every time you make a change and end up costing you more time in debugging and saving face with your customer than it would have if you had done things correctly from the start.

Jeff goes on to talk about his quality views, which sparked many of the posts:

… There was this quote from Frank Zappa: "Nobody gives a crap if we’re great musicians." And it really is true. The people that appreciate Frank Zappa’s

See I think that’s where you’re wrong Jeff. I do care if I’m a good coder and I care if those on my team are good coders. Not because I can walk into a room and say I’m a great coder, but because I know it pays off in the long run. And Joel/Jeff, you can only appreciate what you’re talking about in your podcast if you’ve truly been coding for years.

[delphi]

There is a human tendency, albeit a bad one, to stereotype. Take for instance the words traffic and chaos. In many cases, you can imagine a chaotic crossroad in India or China, with people and cars crossing in all directions. It’s not because there aren’t traffic jams anywhere else in the World, it’s because of stereotyping. We are constantly sent links and funny videos of horrendous traffic jams in certain countries, and that is why these images come to mind. 

(Picture by http://flickr.com/photos/joiseyshowaa/ under CC 2.0)

Take for example the above image. I found it by typing in the words "traffic jam" in Flickr. It was the first one that popped up. Do the same in Google or any other search engine for images. You’re bound to get a large proportion of similar images. I didn’t even have to use the word chaos.

Consider a Project Manager, could be of any type of project, but for the sake of this post, and seeing that not only myself but many of my readers are somehow involved in software development (except those that find my blog because of this post or this post), we’ll consider the project is software. John, the Project Manager has been accustomed for many years to the Waterfall Methodology. There is a clear and precise line of what a project should consist of and a diagram of how it should be performed.

One fine morning, Bill, the CEO, calls John into his office and says

John, I read this thing on CEO High Flyers’  magazine on the plane yesterday, called Agile. I want us to do it too. I’m not sure what it is, but I’m hearing good things about it. Let’s become Agile.

So John goes back to his desk and starts to look up this whole Agile thing. He reads a little bit about XP, some things on Scrum and goes back to Bill the next day.

Bill, this Agile thing is insane. It’s pretty much anyone does whatever they want and there is no control at all. Take this: they’ve got this "methodology" called Scrum, where people don’t even get tasks assigned. You believe that? And there is absolutely no clear design phase, no testing, it’s completely and utterly absurd. It’s just chaotic.

Bill wasn’t too amused. No tasks assigned? No control over who does what? Anyone can do as he or she pleases? Nonsense. He’d have none of that.

John at this point felt relieved. He’d been running projects using Waterfall for years, and albeit, yes they did run a little late, yes, sometimes the customer didn’t really get what he wanted, yes many times the actual design had to be thought out again, but there was control. As long as there was control, it was ok. Agile on the other hand just seemed chaotic.

Stereotyping is also caused by lack of understanding, by being prejudice.

Is John to blame? Not at all. John was a developer himself once and he’s been "brought up" one way. He’d constantly been shown that the only way for a project to succeed was to have a clear definition of what each person’s role in the project was, what the exact phases were and what he had to work on at any given moment. To now throw that all away and take on an approach such as SCRUM where there is no task assignment, there are no clear boundaries between requirements, design and implementation, seemed too chaotic.

But is it really chaos? Is Agile about disorganization? Is Agile about no up-front design or testing? Here is where it gets difficult. Agile is like SOA, depends who you ask, at what time, at which location and you get a different answer. All of them are similar, but each person gives his or her definition of the word.

To define Agile in one sentence, Agile is about adapting to change.  Agile is not SCRUM. Agile is not XP. Agile is not about throwing design or testing out the windows. Agile is about being flexible, about being adaptable. How you go about doing that is another matter.

Waterfall does not fit in with Agile because it is rigid. There is a clear distinction about the different phases in which a project should be executed. By stepping outside of those phases, or going back, you are essentially breaking the methodology.

SCRUM is an alternative to Waterfall that fits in with Agile methodologies. Why SCRUM works and how it improves over traditional software management methodologies has largely to do with the people behind the project. I’ve covered two essential qualities that a team should have previously in a post about multi-disciplinary and confident and reliable team members.

However, the path to adopting SCRUM or any agile methodology is not easy. It takes time and discipline. The benefit though is that the ROI is very high.

What SCRUM is and the advantages it has over Waterfall, both for the team and ultimately and more importantly for the outcome of the project is best left to a future post. What is important to understand though is that Agile is not chaos, nor is it about doing away with practices. Try and not stereotype it.

Just noticed this under one of the Build failure notification e-mails received from the TFS daemon:

 

- You are receiving this notification because of a subscription created by xxxx\Hadi Hariri Provided by Microsoft Visual Studio® Team System 2008 <http://msdn.microsoft.com/vstudio/teamsystem/>

Notice there’s no "If you do not wish to receive future notifications please….."

Nope, you’re screwed. Your best bet is to not break the build…or break me!

Visual Studio comes with TODO markers where you can mark sections of code with little comments to indicate that you need to do something. However, TODO sometimes becomes too generic. You start to mark tasks, features, futures, (bugs have their own by default) with the same tag. Fortunately you can add custom ones. If you have Re-sharper installed, you get additional benefits since it allows you to create filters, identify the tags inside comments and highlight them on the right margin.

One tag to add is SMELL. A code smell is a piece of code that works yet it just isn't right, and you know that the longer it's left in there, there worse it can get. It can lead to an unsustainable situation where the whole project can start to smell like a dump site. Other times it's just a small section that is isolated and won't have immediate side-effects, but would be good to get it cleaned up.

Now, I know the purists would probably scream and say that any smell should be eradicated then and there. Snap back to reality. Both you and I know that that's not always viable. Having said that, If it's a bad smell that can lead down a spiral of stink, then yes, it should be, taking into account schedules, etc.. but even in that case, you're not going to do it all at once, so you still need to identify the smells as you go cleaning them up.

Here's some screen shots of smells with Resharper

To define them, use Resharper's To-Do item entry

You can also see on the To-Do Explorer

I read a post today about how there should be a plug-in for Visual Studio to disable copy/paste, in order to prevent people from copying and pasting the same code over and over again, instead of applying basic design principles (DRY). Now I’m sure the author didn’t mean this in a serious way (it’s hell to be without copy/paste, and if you don’t believe me, use the iPhone for a couple of days), but it reminds me of recent discussions about RhinoMock vs TypeMock, or put another way, TypeMock vs every other mocking framework out there.

The main discussion was that TypeMock could lead to malpractice. By using TypeMock, people could potentially end up with tightly coupled code. Since there isn’t a need to inject dependencies, you could create dependent objects in your classes. I posted my thoughts on this a long time ago (too far back for Live Writer to show it up in recent blog posts), so I’m not going to get into too much detail, but suffice to say, I didn’t agree then and I still don’t agree now.

But what has that got to do with the copy/paste post you might be asking yourself. Well I think in both cases, we are showing signs of wanting the tool/framework to do the work for us, to police us, so to speak. Which begs the question, why?

I work on a team, as a tech lead. The part about work is questionable, but nonetheless I am on a team. Part of my job is to oversee my team and make sure that things are being done correctly. In my book, correct means applying good design principles. It is my job to make sure that my team applies these principles. If a team member is new or is not familiar with certain concepts, it’s my job to teach them to him/her. With new team members, there is normally a period of code-review, where during check-ins code is reviewed by senior developers (either myself or someone else on the team) to make sure that they comply not only with design principles but standards of coding and practices. However, as time elapses, code reviews become less frequent (although there should always be peer review on a team from time to time). So initially it might be a time-consuming job, but in the long run it isn’t. In many cases it’s also very productive since there’s always something new you can learn.

If people are taught things in a way, that not only do they understand, but see what happens when they do it the wrong way, they will act correctly.

Developers are not stupid.

In my previous post, I talked about confidence and how it plays an important role in the adoption of SCRUM. The next aspect of a team, specially the smaller ones, is that the majority of the team members need to be multi-disciplinary, in other words, need to wear multiple hats.

A Scrum project is divided up into sprints which can be anywhere between 2 and 4 weeks (ideally). Before each sprint, there is a planning stage, where items are taken off of the product backlog and planned for the sprint (I’ll talk about how we plan in another post). Once the number of items are selected, the sprint starts and team members start to work on them.

Now here’s one important detail: in true Scrum, and that is Scrum that really works, there is no task assignment. The Scrum master does not assign tasks to team members. Tasks are self-assigned by those who work on them.

From a perspective of a team leader, be it a technical lead or project manager, this might not seem such a great idea at first.

How can I be sure people will get things done?

How do I know how much Joe has done and how much Jack has done?

What if John is pulling all the weight?

Obviously, as members assign themselves tasks when working on them, all these questions are answered in the first sprint. But here’s a more difficult one (which recently came up in a conversation with a colleague):

What if Jack is taking all the easy tasks…it’s human nature to be selfish and aim for the least effort

In my book, it’s not human nature. And in my book, Jack has no place on my team. In other words, if you have a team member like Jack, get rid of him. You don’t need him.

This self-assignment of tasks and not having to micro-manage people (which is always a good thing), brings on another issue: you need multi-talented people. In the same way a project can fail if your bus number is low, a sprint can fail and consequently your whole project can get delayed because of the same issue. When a sprint is planned, and all members have agreed on a list of tasks to work on, these are regularly categorized, be it due to technology, business or any other factor. People tend to stick to a certain category. If Joe has been working on the back-end, he tends to pick tasks that are related to that area. If John is working on reporting, he’ll pick out tasks of that nature. This isn’t necessarily a bad thing, unless it becomes pathological. What cannot happen is for Joe to refuse to work on something that is not directly related to his area. If Joe runs finishes his tasks and he only sees a list of tasks that fall out of his area, he needs to be able to jump in and grab one of them. Otherwise, the task remains there until John, the "owner" of that area can work on it, who happens to be working on a previous task. What is even worse is if Joe does have a task in his area, but that it depends on another task which is not in his area.

What ends up happening is that John is causing a bottleneck. The time that Joe is waiting is ultimately time that is lost, which in turn is translated into a delay and consequently a failure of the sprint.

Therefore, it is very important for team members to have the knowledge, and more importantly, the confidence to confront different situations and take on various tasks. This doesn’t mean that they have to do it alone. One of the jobs of a Scrum Master is to remove impediments, and if an impediment is caused by a lack of knowledge, the scrum master, one that also needs to be multi-talented has to act as a mentor and lead, has to guide team members through the different challenges.

Scrum doesn’t work if you sit around for the next guy to get rid of your problem.