Interfaces are implementation details

I believe hiding away the implementations of a code base to be a good thing. I generally try to minimise my interactive surface and make it as user friendly as possible with descriptive names considerate arguments etc.

One thing I have not considered until recently is the very fact that  calling my interfaces IFoo and not just Foo is, in a sense, giving away an implementation detail. is this a .Net thing? Possibly. When I asked my Java mate for his coding standard he informed me that it is common for  quite the reverse to happen in his work place. The implementations of the interface are suffixed with "impl" to imply it is an implementation with the interface having the more user friendly name. Will I change my style? Probably not, as I generally work on other peoples code base and I prefer to stick to language/framework standards, even if they may not be the best (well sometimes).

On a whole other tangent but still discussing interfaces as implementation details Scott Bellware and Greg Young (2 very smart and very opinionated guys) are tussling over this on twitter as we speak.. well as I write..(25/11/2008 ~7am GMT)

Technical Reviews

As you may know I have recently moved back from London to Perth, due to many reason including a credit crisis that means London is not the best place for us to be living.

I have been job hunting with favourable feedback, but not a lot of cash in my pocket. The state of affairs the world is in means a lot of companies are waiting for the new year to hire people. This, needless to say, is not so good for me as I need to eat before then.

I am in talks with a few companies that I hold I reasonably high regard and would be happy to have any of them on my CV in years to come, however the interview process is really getting dragged out.

I have been involved in more interviews test this years than the all my previous years combined. This includes writing them, completing them as a bench mark for my current employer and of course completing them in hopes of a new job.

My disdain for them however continues, yet I understand they are somewhat of a necessary evil.

The problems I have is:

• Most test technical knowledge, i.e. my knowledge of a library, something that becomes obsolete very quickly. I do not hold this is very high regard. Core concepts are much more important to me, I can get someone productive in ASP.Net in a day or two, I cant teach them OO coding that quick.
• A test that tests coding ability tend to be short and inane. Ironically these to me are more beneficial, because now I get to see the workings of their mind and their coding style. Still I have never done a test that dealt with interaction, which is unrealistic for an enterprise developer, and is a place where most intermediate devs fall over. SoC is still something many struggle with.
• I have never seen a test that tests ability to write enterprise code... which is what I do, the technologies are implementation details. Design, interaction and domain logic to me is much more important

How would I fix these? Well my first approach would be by talking to the candidate. The time it takes to mark the test could be done talking to the candidate, you are going to have to anyway. keep it brief; in 10-20 minutes I would have a very good understanding of what the candidate knows.

Secondly I would sit with them and get them to write some code. again in 20 minutes I will ascertained what I need. The type of person to me is of utmost importance.

If you are taking a interview type test be sure to get something out of it. You are investing your time so there should be some sort of return, ideally a job, but at least feedback.

You should be able to tell straight away what you are not comfortable with, today I realised my knowledge of IIS is not up to scratch. I do not need to see my results to know that, I know I got the answers wrong. I have highlighted a weakness. Now it is up to me to decide if that is a weakness I want to address; time is a limited resource, do I spend it on learning IIS? Well I am going to have to, my ignorance is unacceptable. Will I go for guru status? No chance, I don't value it that much.

It is also important to push the interviewer for feedback, critical feedback, personally I want them to be borderline nasty. If they tell me I was awesome and don't give me a job, well then something is wrong. Find out what. If they say you were crap/"not right for the position" then find out what set you apart from the others and what you would need to work on. Be forceful. HR will be fluffy, ask for concrete reasons. Was it because I suck at IIS? Asking for too much in terms of reimbursement? Do I smell funny?

Note to recruiters/employers:

Please update your tests at lest yearly. Asking questions about

• IIS 5 when IIS 7 is out,
• ADO (not ADO.Net)
• SQL 2000
• Operating systems that are 8 years old

may give insight on the candidate and there knowledge of legacy stuff, but it also reflects a certain something on your company and what the candidate will come to expect. I will certainly be favouring the company asking about TDD, ORM and C# 3.0 features over one grilling me on VB 6.0, Com interop and Access.

Process refinement: Lean

Lean* is a buzz word I have been hearing for a while and know guys like Dave Laribee are right in to it, which is really reason enough to have a look. My knowledge of Lean was only anecdotal until I met  a lovely young lady in Melbourne  who was in fact a Lean specialist. She is old friends of my partner (Tori) and much to Tori's disgust we talked nerd a fair bit. It was cool to know that she actually had a Software and Manufacturing background and is applying Lean in the traditional manufacturing sense with a very large manufacturing company.

So after speaking to this Lean specialist and seeing her enthusiasm for the process I picked up a book I have glazed over a few time of the bookshelves: Implementing Lean Software Development. It is part of the Kent Beck series and all of the books of that series I have read so far have been worth the effort and cost, so I thought "why not?".

What I like about Lean is how it works well with Agile & XP practices, it defines things we already know work, but often the act of defining or providing a framework is in itself beneficial. It is something that can be easy for managers to understand and easy for dev's to apply. For the (second to) last project I worked on in the UK this book would have been a welcome addition to the library. Errors in our process were evident, but you still need to define and identify them to fix them, this book would have helped in this regard.

Anyway my understanding is still growing, but so far so good, the book is well written and should be done by the end of this week, just in time to swap with what ever book Gumble brings me from London... hint hint...

*Uber brief back ground for those not too familiar with Lean:

Toyota came up with some some cool ways to make stuff better, these principles and practices have lead Toyota to being one of the most efficient manufacturers in the planet. Core concepts have been extracted from Toyota, Lean is one of those by products. Since software dev has similar parallels to manufacturing some of this P&P have been applied to define Lean software development.

Postsharp and sanity checks

While playing with Postsharp for a validation framework i stumbled upon this.
This is a great little code block that stops sneaky team members referencing layers they should not be referencing. a compile time error will ensue and let them know, for example, that they can not access the DAL via the View projects... happy days!

Yay!! New books!

Having left the UK and my library behind *weep*, I am now virtually bookless.. other than WPF books... So new additions have added, specifically "Implementing Lean Software Development" and "Applying Domain-Driven Design and Patterns", 2 book I have been looking forward to reading for a while. As I am stuck on public transport or away from my computers a fair bit, conceptual books are probably a better investment than purely technical books; learning WPF without a PC is not that easy and a little hard to retain!

So back to antisocial booking reading in the car/train/bus/waiting room/restaurant/movies... um, well yeah.

Easy performance increases

Patrick has posted an interesting article on foreach performance stating that a for loop with an array is up to 5 times faster than the same code executed in a foreach on List<T> (assuming the contents is the same, just the container type is different). This wont affect most of us, however if you have a situation with nested loops this could be a significant performance improvement.

Web Development

My original roots in .Net were very much in ASP.Net. My first real dev role was in .Net 1.0 on an early e-commerce app that had its early prerelease roots in classic ASP. I really enjoyed ASP.Net but found myself moving away from the front end and more in to SQL and middle ware as I worked on larger project.

Over the last couple of years I have not had a lot of commercial involvement with asp.net front end. I had the (dis)pleasure of some win-forms front ends on my last contract but mainly middleware/domain/messaging level stuff.

So I thought I had really fallen out of touch the other day when my partner mentioned that a company she was working for was paying $X for what was basically a brochure-ware web site. This value was around the monthly wage of a dev in this part of the world. I could not believe it. I told her to make sure they got a price break down and said (more out of example) that I could probably do it in 2-3 days. The price break downs were just silly and I was shown the concept of what they wanted. This was on Monday night. Tuesday afternoon I had a fully functioning site that met all of the requirements and look pretty good. I gave a demo to the missus and with a few CSS changes the site was done. Hardly a months work. The other benefit is the site is built in a framework that allows for extension of functionality. The company may may need email marketing, blogs, newsletters and basic site management, something that was not available from the other vendor. I could not believe it, the cheeky little buggers!

It was nice to know that my web skills have completely gone out the window either... CSS; how I have missed you... lol!

DbC edging closer to mainstream!

As you may be aware I am a big DbC fan. So I am obviously stoked to see a couple of things pop of late (sorry if this is old news i am on a big holiday at the moment so finger is not really on the pulse)

1: The System.Diagnostics.Contracts name space. Thanks goodness this is getting put into the core libraries.
2:http://social.msdn.microsoft.com/Forums/en-US/pex/thread/14115b4d-52c1-4e93-89cd-19db3fd86756/
A temp forum leaning on the PEX* team ;)

My first up impressions.
Well its good that it is non longer 3rd party ie Spec#, well at least moving out of the lab and into real .Net
The code is in the method body, which i think is ok as an option but i would like to have more visible, or perhaps more logically located. Spec#s incarnations looked pretty good to me.

Anyways this along with TDD should be making for some pretty robust libraries. looking fwd to getting my pc back and having a play.

*PEX is a whitebox testing frameworks that looks pretty cool too :)