Shane Courtrille's Blog

Some of these I’ve done.. some I’ve just seen.. but they are all now things I watch for…

1. Never talking to someone who is going to physically use your solution…
2. Not having acceptance tests…
3. Showing up for your new job and being handed a few binders worth of the design that someone who has already quit did…
4. Working at the same job for so long that it makes you think about becoming an electrician…
5. Not practicing TDD…
6. Having only half a team that understands DDD but trying to do it anyway…
7. Not listening to your gut for a hiring decision…
8. Writing integration tests to do the job of acceptance tests...
9. 3 BAs for 10 developers..
10. 2 QA people for 10 developers…
11. Not understanding your audience…
12. Listening too much to others…
13. Too much reading.. not enough doing…
14. Thinking that you know everything…
15. Believing that you know nothing…

I could keep going but this seems like a good enough place to stop for my upcoming rant…

Recently I ran into an interesting problem on a small project I was working on.  The problem was on the surface fairly simple.  Take a currency amount and round it up to the nearest 0.05.  While the solution is not earth shattering it took long enough to figure out that I figured it was worth recording for my future self. 

The first part of the problem is to round to 0.05 which is accomplished by doing this (thanks Google..):

decimal initialValue = 0.56;

decimal value = Math.Round(initialValue / 5, 2) * 5; 

But the problem is this code will actually round to the nearest 0.05 as opposed to only rounding up.  So 0.62 will round to 0.60 where as our requirement is to round to 0.65.

But that part of the problem is actually fairly easy to solve..

if((value - initialValue) < 0)
{
     value += 0.05m;
}

And there you have it.  We can now round up to the nearest 0.05.

So this weekend I had the chance to give a presentation at the Edmonton Code Camp.  I’ve done this every year for the last few years now (and I’ve done a few presentations elsewhere) and I have to say that this by far was my…. worst presentation ever. 

So what went wrong?  Well the primary problem I think was based on the fact that my original presentation idea was going to be a fair bit more advanced then the talk I ended up giving.  Originally my idea was to talk mainly about the differences between Unit and Integration tests.  While there are some fundamental differences between the two I honestly don’t know that I could spend over an hour talking about them.  As I worked on my presentation though I realized that there was probably a lot of value in talking about some more basic testing stuff first.

So this is where my mistake happened.  At this point I should have probably thrown out all of the advanced stuff I wanted to talk about and started fresh.  Instead I tried to walk this line of keeping in line with my original idea while trying to talk about the basics of testing first.

BAD IDEA…

I found the talk quite dysfunctional because it tried to bounce between intro level and advanced level which never works well.  So with that said here are a few things I take away from this..

1. Intro and Advanced level talks have totally different audiences.  Pick one.

2. If your original idea is wrong.. that’s fine but throw it out and start fresh.  You may bring some stuff forwards but it’s good to start with a fresh mind.

3. Semi unrelated but I really need to get started on my blog series on testing I wanted to write.  Good news is I mentioned it while talking to a few people after my talk so now I have no choice.

Living and Learning…

Recently I ran into a situation where one of our WCF Operations was taking a long time to complete (in the range of a few minutes).  The problem was that while this was going on the server stopped responding to all other responses. 

After a bit of time with Google I was able to find a post that seemed to explain the problem we were having WCF Threading Internals (Updated). 

At the end of the day the solution (which took a bit more work to find) turned out to be fairly simple.  It involves making your Operation asynchronous via the AsyncPattern contract parameter (and a bit of other stuff).

So lesson of the day is.. if your WCF Operation is going to take a long time.. Asynch it.

I’m happy to announce that the “My Job Went To India…” book I talked about in an earlier post is being re-released.  This time the title has been changed to The Passionate Programmer: Creating a Remarkable Career in Software Development. 

I’m quite happy to see the re-release and name change.  I think the earlier name cast this book in a way that might have limited its audience.  This is quite unfortunate when you consider how valuable this book is for every developer to read. 

I’ve got the earlier version but I’m definitely going to pick this one up as well since I found the first one so valuable.

Well the last month has been a bit hectic around here.  Between moving and being sick twice I’m just getting to the point where I’ll have some time to type out some of the random thoughts and maybe a few more book recommendations….

Gregory Beamer is writing an interesting series on Linear thinking.  I think the PoEAA name for what he’s talking about is Transaction Script and boy have I seen a lot of it. 

One of the problems that Gregory brings up is large classes.  Now I haven’t seen the classes in question but to me it seems smelly that the class is complex enough that Gregory would need to use screen splitting to see the variables that exist for the class and the rest of the code.

In following with some fairly common advice I’ve switched to the small method style.  I try to refactor all my methods so that they are around 10 lines or less and then name things appropriately.  I’ve talked with co-workers and they do agree that it helps make the code more understandable. 

One of the other things that I do though is to try and keep my classes small.  I obviously don’t always succeed at this but if I see a chance to take a piece of functionality in a class that can happily live on it’s own I will let it by creating a new class.  I then move all the variables and methods into that class.  I was going to mention this on Gregory’s post but while writing my comment something struck me.  The one problem with this method of working is that it does create a lot of classes.  Now to some people I’ve ran into this is a big deal.  To me it’s not a big deal at all and when I really think about it a large reason that it’s not a big deal for me is that I can use ReSharper as easily as I can use notepad.  After years of usage ReSharper has just become a natural extension of the IDE for me that allows me to quickly my code. 

So the question then is is this valid?  I find that the classes make a lot more sense, have a higher cohesion and lower coupling then otherwise.  These things obviously are good things.  But is the increased cost of navigation and potentially understanding worth it? 

As I look at my list of projects I consider as being active in my life ala Getting Things Done I realize now that I am…

1. Trying to do way too much at once.
2. Focusing way too much in one area.

These are really important things to realize.  So even if you don’t go full blown GTD I suggest taking 10 minutes and writing down every ‘project’ you are thinking of right now.  Once you’ve got that list, evaluate it and make sure that you’re being realistic with yourself about how much you can do (Currently I think I’m equivalent to a single core with 50 apps running). 

And then make sure that you’re not focusing too much in one area.  If all you’re working on right now is code make sure you do something to improve your soft skills (oh that’s right.. I need to add Toastmasters to my @Someday list) and if you’re heavily into soft skills make sure you find some time to read about what new techniques the kids are using. 

Well rounded people are just as nice as houses with rounded corners.. or something like that (Funny what seems funny at this hour..)

Or as I like to call it… “The day of the Coder is over..”.

While the title of this book implies that the target audience is people who feel their job is in danger from outsourcing I think it has a much wider audience.  In fact I would suggest that almost everyone who writes software for a living can find value in this book. 

I am a strong believer that the day of the Coder who sits in the corner writing code without ever interacting with others is quickly fading away.  In today’s market it’s important that we all understand how we can make the transition from Coder to Software Developer.  I myself have been working at making this transition (hence the soft books) and I found this book very valuable in doing so. 

The book is packed full of 52 different two to three page sections broken up into 6 parts.  The sections run the gambit from choosing which technologies to align yourself with to how to make yourself more appetizing to people who are hiring.  Out of the 52 sections there are a few that I don’t agree with but in general I found each section had something of value for me. 

The one thing I really liked about this book was that almost every section ended with an ‘Act On It!’ list.  This list would contain various activities you could do to strengthen yourself in whatever the section had talked about.  While there is plenty of value in just reading the book I personally always find I learn a lot better if there is an action I can take.

This book gets a strong buy recommendation from me for every one in the software development industry.  If you are willing to take the time to read it and try some of the various actions listed in ‘Act On It’ I think you’ll find this book as interesting and valuable as I have.

I once had the fortune of working for a company that went out of its way to make sure the customer was always happy.  The benefit of this simple behaviour was huge for this company.  Word of mouth on our product was huge and more importantly when customers did have problems they were happy to give us the time and assistance we needed to resolve the issue.  Customer support is what made that company as successful as it was.

  For this reason customer support continues to be an area of interest for me.  I always find it funny when companies seem to go out of their way to provide a bad customer support experience.  Of course that is what makes the companies that provide a good customer experience so valuable.  These companies are always looking for new ways to interact with their customers.  Two examples of this recently came to my attention and I thought they deserved a mention.

The first is how ReSharper by JetBrains handles exceptions.  (It’s possible that the rest of their software does this as well but I’ve only noticed it with ReSharper)  When an exception occurs the user is provided with a popup letting them know.  More importantly though they are given the option to report it to JetBrains.  Either anonymously or via their JetBrains id.  Now up till now we’ve got behaviour which has become fairly standard.  Where JetBrains goes the extra mile is in how they handle things post reporting.  Once you report the bug you are given a link to the JIRA ticket.  This allows you to keep track of the problem and find out when it’s been resolved.  Even nicer is that if you used your JetBrains id you will be notified of any changes in the defect. 

The second way in which I’ve seen companies pushing the customer support envelope is in the use of Twitter.  I have twice complained about an issue I was having with a product and in both instances I received a response via Twitter that resolved my problem nicely.  The funny thing is I didn’t expect a response.  I was just complaining but that complaint got turned into action.  So far it appears that DevExpress, ViEmu and JetBrains are all using Twitter in this manner.

I think the lesson one can take from these two examples is that there is almost always something else you can be doing to improve your customer support experience.  If you can’t come up with any ideas on your own then feel free to see what other people are doing (not just your competitors.  You want to be customer support #1 in your niche which means going beyond what they are doing.).  You may find a new way to support your customers which is always has value.