Due to mostly uninteresting reasons, I’ve been running two different feeds to this blog:

http://feeds.feedburner.com/hadihariri/rSpO

and:

http://feeds2.feedburner.com/HadiHariri

This second one is the valid on. I’ll shortly be removing the first one (in about a week). There’s over 200 subscribers to it, so please, if you’re one of these, could you update your feed to the new one? Once again that would be this

Thanks.

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).

Oliver Sturm and Gary Short, from DevExpress have started a new podcast. Having recently met up at a conference in Germany, they decided to make me their guinea pea. Thus if you're interested in hearing two ugly guys (and myself) talk about a bunch of different things, check it out. The only thing that doesn't surprise is what they've called it.

It was fun guys. Thanks!

(P.S.: I talk about another Podcast in it but I won't spill all the beans just yet....)

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.

That's the last time I ever ask for a Doggy Bag!

And that's not food the Dog is looking at.

My mother wants to become a computer programmer (not to be taken literally). And guess what, she can. With all the RAD environments nowadays you really don't need to know much about the basics of programming to make applications. You can use anything you want. First step, pick an environment. You have lots to choose from (Visual Studio, Delphi, Ruby on Rails). In under 1 hour you'll have your first application working. Next step, sell it.

Now do this for about 10 years, making a profit and you can claim that you're successful in software development. You can claim you've worked for 10 years and have never had to worry about things such as polymorphism, delegation, etc.

So when someone comes along with a post talking about weird things such as SOLID or how rules are meant to be broken, you reaffirm your position as a successful developer that has never needed or understood these concepts. And since the person writing this has 1.5M visitors a month and 125K subscribers, it's OK!

(You think I'm crazy. Read some of the comments on this post).

But It's NOT OK

I don't lose sleep over what I term demoware cowboys. Everyone has a right to make a living, however way they want. I'm the first person in the room that stands up to defend not needing to graduate in CS to have a successful career in software development. However, I also defend studying, understanding and practicing software engineering, and to continuously improve yourself. Just because you sell software and put food on the table doesn't mean you've accomplished all there is to in your field.

What does bother me however is people talking about things without truly understanding them. It's important to act with responsibility, specially when having so many followers.

Some of us write software for a living, as opposed to just writing about it,  and it's not only about getting the job done.

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]

Excellent! I've been renewed as MVP C# for the 2nd year. I enjoy a lot working with the community and it's great to get this award. 

Thanks Cristina et al.

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