Phil Bernie Consulting

I was reading a couple of posts the other day and it got me thinking about my current work situation. The first was a post on Coding Horror called Learning on the Battlefield and the second was Scott Hanselman’s post on Sharpening the saw for developers.

I often try to think of ways to learn new skills and actively try and learn about the latest patterns and concepts and it’s great to fill up on “theory” but so far I’ve found nothing better than rolling your sleeves up and getting your hands dirty with some code to really “Sharpen your saw” so to speak.

I’ve been doing a lot of work on a project that has had me writing and reviewing a lot of SQL code and it highlighted a couple of deficiencies in my SQL skills so I was glad to be brushing up in that regard, but that wasn’t what has interested me most about working on this project.

It has been surprising to notice there’s an underlying skill set that is being developed that is not as recognizable as the direct skills you’re learning. I’m finding more and more that it’s becoming easier to know where to apply different skills depending on the situation.

As I think about it, it has become clearer that the benefit of experience isn’t so much what you learn, but where you apply what you learn.

Take a high quality grad developer and a high quality senior developer with 5 or 6 years experience and ask them to learn about a technology. All things being equal I would expect them to learn the technologies equally well. The difference between them is how they use the technology.

More often than not the grad developer will take the approach of learning a technology and once learned find everywhere it can be applied.

A good senior developer will take the approach of learning a technology and evaluate whether or not it can be suitably applied to a given situation.

Of course these are just blanket statements but the more I look for ways to differentiate between the good developers and the great developers, the more I realise the differentiator is not what they know or what their skills are, but their ability to quickly and consistently choose the right way to solve a problem.

It’s not just good enough to solve a problem. Nearly any Joe Developer can solve a problem. It’s the ability to quickly evaluate and then decide on the optimal solution is what makes the difference. The better the developer the quicker they’ll discover the pitfalls of an incorrect solution. The best developers can not only say why the solution they chose is optimal, they can articulate why they solutions they discarded are unacceptable.

So where does experience come into this? Well there are a few exceptionally talented developers that will consistently choose the right path, no matter the situation, however for the rest of us, we need to actually experience the pitfalls before we can understand why a solution isn’t optimal and where it can be applied in future.

It’s experience that tells us that NHibernate is a good fit for a complex domain project, but may be overkill for a simple console application that only updates statuses on a few rows.

It’s experience that tells us that MSSQL reporting services is a good fit for our basic reporting needs, but we will need something more comprehensive for reporting against our data centre with terrabytes of data.

And it’s experience that gives us the knowledge to make these decisions early in the process instead of committing heavily to a suboptimal solution.

Whilst I would never hire on experience alone, in future I will be keeping a keen eye out for talented developers that have a diverse range of experience and can talk me through their thought process when choosing a particular solution to a problem over others.

I’ve been working with a tool called Tibco DataExchange the last couple of weeks and it’s been frustrating. The problem with Tibco DataExchange or “DX” as it’s known is that it’s a development tool, designed to provide a level of abstraction away from the “code” however it provides you with no way to drop back to view the code. It’s just magical fairies in the background doing what it thinks best and I hate it.

I don’t have a problem with visual tools that assist in making coding easier but I do take exception to tools that think they no better than you, and as such, hold you hostage to how they feel like implementing their solution.

A lot of people complain about the “drag and drop” mentality that Microsoft take to a lot of their development tools, however one thing they get right is that their visual tools are often little more than code generators. You can always drop back and work right in with the code.

The same can’t be said for DX.

I’ve worked with many visual tools and the best ones always have the same properties.

1. They excel at the basics and make it easy to leverage them to get up and running quickly so you get a good amount of benefit from them early.
2. They know their limits and get out of the way when you need to start doing some really heavy lifting.

Take a look at any visual tool and the ones you like will have these properties. They do what they do well and once you get to the point where they can’t help you anymore, they get out of the way.

Windows live writer is a good example. It makes writing blog posts dead simple, but if you need to make a custom layout change, you can drop to source view and do it yourself. It shows you exactly what it’s doing under the covers and lets you decide if that’s really what you want

Tibco DX is not a good example. It hides what it’s doing and gives you no way to choose an alternative. Instead you have to hack around the tool and you end up wasting so much time that you lose any initial value you got from allowing it to do the basics.

Given the choice, I’d rather a feature poor tool that got out of the way when it was no longer useful, than a feature rich tool that locked you in and gave you no choice to do it any other way but theirs.

Rob Conery posted about why he thinks it’s important to learn MVC and I agree that it is important to learn MVC and his points are all valid. The point that’s missing though is this: So you can have an informed opinion on what the benefits are of MVC vs insert all other web technologies here.

Within MVC itself there are some interesting questions to answer like what MVC framework to use. There’s actually more than just the ASP.NET MVC framework, and even if you settle on ASP.NET MVC, you’d be wise to also evaluate the different viewengines,  the different controller conventions and the various routing styles.

If you get asked your opinion on whether MVC is going to be more suitable than WebForms for a new project you’re starting, there’s only one way you can truly answer that question with any authority and it’s from having a good understanding of what MVC offers. The best way to get that understanding is to learn it.

This holds true for pretty much any comparison. Is the Entity Framework more suitable than NHibernate? Is MSSQL server more suitable than Oracle? Are Macs more suitable than PC’s?

You can read as many articles as you want to get a general feel for what each has to offer, but the only way you’re going to get a truly valuable opinion is to roll up your sleeves and get dirty with the tools.

Even just building the most basic applications will tell you what the friction points are, what the benefits are, how this technology will require you to approach the problem and ultimately form your own opinion.

I agree with Rob, you should learn MVC, but I’m adding another reason to the list.

I’ve resisted the urge of learning a dynamic language like F# or Ruby for a while but it’s hard to ignore that the deeper you go into c# the more it gets in your way. In the last 2 days I’ve had 2 problems in c# that simply wouldn’t have existed in a dynamic language.

First problem I had was needing to assign multiple values to an object property but I wouldn’t know the type of the value until runtime. The property was an int, but I could potentially assign a decimal or a long depending on what was returned from the underlying data source. Because c# requires static typing I had no choice but to choose an int as the property type and then do a bunch of crazy casting to handle the various runtime issues. In a dynamic language, I’d just assign the values and the type would be inferred.

The second problem I had involved variance with generic collections. The situation was that I had an interface called IParcel which was implemented by  two classes, Disposal and Parcel. I also had a function that accepted as a parameter IList<IParcel>. The problem was that I couldn’t pass an IList<Disposal> or IList<Parcel> to the function even tho Disposal and Parcel derive from IParcel and therefore should be considered perfectly valid. Instead I had to call ConvertAll() on the collections to convert them to IList<IParcel> objects and then pass the converted list to the parameter. In a dynamic language, I would just pass either list into the collection and life would go on.

Variance is being addressed in c# 4.0 but it’s only one circumstance where these sorts of problems begin to hit the limit of what c# can do.

It will be interesting to see what direction Microsoft takes with C# and dynamic languages. It seems that they’re looking to accommodate dynamic typing within C# as much as possible but where pure functional programming is required they’re pushing people to F#. This makes good sense but I wonder if the lines will become blurred by allowing easier access to F# from directly within C#.

Whatever they do, I don’t think I’ll be making a full blown switch to a functional language soon but I’ll be watching what happens in this space as there is definitely room for some interesting solutions to these interesting problems.

Well it seems Iron Speed are at it again with their ridiculous licensing policies. I received an email from Iron Speed which contained the following information:

Beginning with our upcoming Version 6.1, Iron Speed Designer can be installed only on one machine at a time. Simply uninstall Designer to move to a different machine. As with earlier releases, your software license permits one named user to run on one machine.

For years, power users have purchased extra licenses so they can run on multiple machines. If you’d like to use the product this way, we are pleased to offer a special one-time 30% discount on additional licenses for yourself or other currently licensed developers on your team. Please contact your sales representative to assist you with a purchase or email sales@ironspeed.com.

This offer expires on April 23, 2009 and will not be repeated.

There are 2 things that annoy me with this “incredible offer”. First is that they’re actually making it harder for you to run multiple instances of the designer. From what I’m reading, you can no longer activate and deactivate instances, you actually need to uninstall your copy of Iron Speed to transfer it between machines.

Second, they are giving you the opportunity to buy more licenses so you can run the software you already own on more than one machine. It’s completely absurd. If you do any sort of consulting work, there’s no doubt you’ll have multiple machines. I personally have 2 laptops and a desktop. At any given time, depending on the job I’m doing, I could be on any one of the three computers. It’s just not viable to have 3 licenses of a single product to use on those machines. Throw in the fact that I can’t even run Iron Speed from within a virtual machine and you suddenly question whether Iron Speed have any idea what they’re doing when it comes to licensing and marketing.

Iron Speed have a decent product, but the ridiculous nature of their licensing continues to annoy me so much that I will refuse to purchase from them.

There’s a bit of buzz around Domain Driven Design at the moment and while I haven’t gone too deep with DDD, there are certainly some aspects which have challenged the way I’ve been approaching problems.

In the past I’ve used plenty of ORM tools which are heavily dependent on the database and this reliance often results in a domain model that directly represents the database table schema. This is often a quick and convenient method of creating a data layer and it works well for the most basic of CRUD applications, however when your applications begin to get complex, this method can be left sorely wanting.

What has interested me most about DDD is the concept of a Doman Context and modeling "objects" based around a specific context. In a recent project this has worked for me in two ways.

First I had a domain context that was based around reporting, where I had data coming from a number of different tables but had to be mapped to a single object. The situation was analogous to having a business that could accept orders online, in store or by mail and each different order was stored in a separate table. I then wanted to create a sales report that showed a summary of all sales in a common format. With ORM solutions I’ve used in the past, I would have 3 objects mapped to my different tables called OnlineOrder, MailOrder and StoreOrder. I would then have had to massage that data into a common ReportOrder object and bind it to my report.

With NHibernate I was able to create a mapping for each table and map them all to the single ReportOrder object. This allowed me to have a nice clear representation of my domain model that was clearly abstracted away from my database model.

The second situation I had was where I had a single table that I needed to be represented in multiple domain contexts. For example I had a Customers table which had one-to-many relationship with an Addresses table and an Orders table. In one context I wanted to update the Addresses and in another context I wanted to validate orders. If I was using an old school ORM, I’d have a Customer object with a collection of Addresses AND a collection of Orders. I’d have to make a choice as to whether or not I wanted to lazy or eager load each collection based on what I was doing with the parent object. With NHibernate I was able to just create two seperate objects that did exactly what was required by domain context. One Customer object had a child collection of addresses whilst a seperate one had a child collection of Orders. This example is greatly simplified but being able to create multiple objects based on specific contexts has meant I’ve been able to greatly simplify my domain model and reduce the complexity of my objects.

I haven’t done enough DDD to consider myself an expert or not, but combined with NHibernate I’ve definitely been given plenty to think about when it comes to modeling my domains.

I’ve been using NHibernate as the back end for a web service and ran into a little problem when returning the NHibernate objects to clients via the web service. I had a Person object which had a child collection of Addresses which I had explicitly set to lazy load depending on the request from the client. The lazy loading was fine, however when I went to serialize the Person object the serializer would check the Address property and therefore cause a lazy load of the Address collection.

I couldn’t find a way to tell NHibernate to ignore future requests on the Address collection once the Person object had been populated so in the end I had to handle it manually and return custom DTO objects via the web service.

As yet I haven’t found a better way to deal with this situation but hopefully there will be a way to remove objects from the NHibernate session or at the very least tell NHibernate to ignore specific objects in session.

In Australia we are in the unfortunate situation where no matter where you are, you have to pay line rental for your landline phone. Then on top of that you have to pay for your phone calls. The catch was that even though I didn’t use my home phone for phone calls, I had no choice but to pay line rental because my ADSL connection relies on the phone line. Even more annoying is the fact that I have VoIP hooked up through PennyTel so even if I did use my home line, I wouldn’t be using the private carrier.

So, my monthly "Telecommuncations" bill looked like this:

• $49.95 for my internet connection through netspace (40gb Downloads)
• $29.95 line rental
• $5.00 per month contract with PennyTel (plus calls)

Which left me with a total bill of $84.90 and feeling like I wasn’t getting great value.

It was also a pain because there was 3 different bills and it was just generally a hassle.

For a while now, Australian ISP’s have been offering "Naked" ADSL plans which effectively allow you to have an ADSL connection through your phone line without paying line rental. It’s not quite how it works, because you do pay a premium for the "Naked" plans. Recently Netspace released their Naked ADSL plans and for me, it worked out being cheaper and better value than ADSL with line rental. I now just have a Netspace bill and a PennyTel bill which I like.

• $74.95 for ADSL through netspace (50gb downloads)
• $5.00 per month contract with PennyTel (plus calls)

I now have a total bill of $80 / month and it’s only a $5 / month saving, however I do get more downloads and I don’t feel like I’m paying for something I’m not even using.

One of the things I struggle with is documentation. Jeff Atwood and Mike Pope both suggest that “if it’s not documented it doesn’t exist ” and I have to agree. Despite knowing how important good documentation is, it often gets put down the priorities list as deadlines approach. So recently I that enough was enough and decided to set aside a day to catch up on my documentation. My goal was to try and document the systems I had been working on recently and I figured that a day would be plenty. 

I downloaded and installed RescueTime recently after reading about it on Tim Ferriss’ blog.
It’s a neat little application that keeps track of where you’re spending your time on your computer. It’s important to me that I know where I’m spending my time but the only way to be able to analyse where my time is going is by collection hard evidence. Since installing the personal version of RescueTime I’m already noticing that I’m actively thinking a lot more about where I can spend my time productively, so from that perspective, it’s a win. It has also highlighted that there’s a lot of time during my day where I’m literally just wasting time in front of the screen. I’ve found myself become more and more aware of it and now, instead of just burning more screen time, I’m more inclined to stop and either get back to doing something productive or take myself away from the computer completely to stop myself going stale.