I asked my brother (CTO, Crew) what he thought of my last post, about competitive advantage. He said it was ‘dense’ and asked if I had run it against a program that calculates the grade level that it targets. So I gave that a shot.

Grade level 14.

Ok, so perhaps that post was a bit heavy. Most of my other posts are in the 8-9 range. But I have been thinking more about it, and today at our company’s software community seminar, I did a short talk on it. One person suggested that I somehow link in the company’s core values. Excellent suggestion. I’ll look at that. In fact, I would also suggest that considering which functional strategy to choose could be done in conjunction with the company’s competitive advantage. Or that perhaps the company might need a mix of strategies among its employees.


Do the tenets of competitive advantage for companies also apply to software developers? Is there anything about competitive advantage that we as the builders of software can learn to assist with our own career development?

I categorize legal competitive advantage for companies in two ways: external and internal. (For the purpose of this article, I am ignoring illegally obtained competitive advantage such as bribery, if such a thing as that could even be called competitive advantage.)

External competitive advantages are things like government-given monopolies or resources, or high entry barriers like legal restrictions.

Internal competitive advantage is anything that the organization creates itself. The book ‘Essentials of Strategic Management’ lists four functional strategies to achieve an advantage: quality, innovation, efficiency and customer responsiveness.

At the moment, the job market is fairly good for software developers in most areas of Canada. But with offshoring/outsourcing, automation, and other threats, setting yourself apart from other developers, especially if you have a long career ahead of you, might be worth your consideration.

Without realizing I was choosing a functional strategy, there was a point in my career where I chose one of these. I picked quality. But what works for me may not work for someone else. I know of other developers who have chosen other strategies. And in fact, earlier in my career, customer responsiveness was probably what set me apart.

Perhaps it’s not wise to choose one strategy for your entire career, but to change as you feel you need to. Or attempt to choose multiple strategies at once, knowing that you won’t be able to give your full attention to a single one. At any rate, it’s an interesting thought/exercise.


As programming students, we are taught how to cast types as rote. In none of my courses was I ever taught that casting was necessarily a bad thing. In fact, C++ even has several keywords just for casting. Casting was just something one had to do in order to look at a variable or object in a different manner. I expect some of the books I have read probably subtly suggested curtailing casting, but for the most part, casting was generally considered fine. (Or maybe they were not that subtle and I just wasn’t getting the point!)

Gradually through my own experience, I have begun to form the opinion that casting is never an ideal solution, but there are times when it’s all but unavoidable. At very least, before writing a cast, it should be carefully thought through.


When changing primitives to other primitive types, I tend to use library functions instead of casts. Library functions are more explicit in their meaning. For example:

float f = 2.5F;
int i = (int)f;

will cause data to be lost. Most, if not all languages, will cut the .5 off and leave i equal to 2. I’d rather make it obvious:

float f = 2.5F;
int i = Math.floor(f);

Now it’s clear what I’m trying to do. If I want to round the value instead of truncating the decimal, I’ll use Math.round().

Upcasting Objects

Let’s establish a couple of classes to use for the next sections: Vehicle is a superclass, and Truck subclasses it.

Upcasting is the casting from a specific to a more general type higher in the type hierarchy (i.e. to a parent class). When would you want to do this? One reason is if the subclass has overridden a virtual method and you want to be specific about which one you call. Upcasting is fine in this case. However, if you are calling a superclass method, the cast is redundant. Leave it out.

Let’s give both our Vehicle and Truck classes a virtual method called drive().

var v = new Vehicle();
var t = new Truck();; // Calls Vehicle's drive method; // Calls Truck's drive method

((Vehicle)t).drive(); // Calls Vehicle's drive method

While a little odd, you might have a perfectly legitimate reason for doing this.

Downcasting Objects

Downcasting is where it starts to get ugly. When you attempt to cast to a subclass, of which your object may not even be the correct type, you get some real ugly code, or worse: class cast exceptions.

((Truck)v).drive(); // Compiles fine. Throws class cast exception

So what do you do if you have a Vehicle object, that you think is a Truck object and you want to call Truck methods on it? How about this:

void method(Vehicle v)
    if (v instanceof Truck)

Ugggh, there’s that ugly cast. Yes it works, and it will compile just fine, but there’s absolutely no protection. Those two lines aren’t tied together in any way. I can change the first to ‘v instanceof SUV’ and I’m back to my class cast exceptions again. You may want to rework how you are approaching your problem. Why are you passing to your method a vehicle object that might be a truck? This is a code smell.

My advice: if you are tempted to cast a variable or object, stop and think if you are approaching the problem correctly. You might be. But you probably aren’t.


I was thinking the other day about magic numbers. I’m sure you’ve come across them. In fact, I’m pretty sure you’ve created them! Everyone who programs has. It might be a value like ‘1980’. What is that? It looks like a year, but it might not be. The general ‘fix’ for a magic number is to replace it with a named constant. The named constant tells the next reader of the code (who may be you) what the intention of the value is.

Replacing magic numbers with a named constant is a specialized case of the general problem of a lack of expressiveness. Nulls are another great example of a lack of expressiveness. You should avoid them wherever you can. Nulls don’t tell you anything about why the variable has no value. Is it missing, not yet assigned, or is there a bug that you haven’t yet found? It could be any of those things, but when you read a ‘null’ value in your debugger, it’s often the symptom of a larger problem that’s much harder to diagnose. Code should not only do what it needs to do, but it should explain why it’s doing what it’s doing, right there in the code. Not the ‘how’. I can read that. I can’t often read the why.

My first blog post here was about making methods very small. I also talked about giving these small chunks names that describe what they do, and in the process, reduce useless comments. This too, is expressiveness.

I’m not perfect at making my code expressive but I am getting better, and that’s all I would ever ask of any developer. A perfect example: twice in the past two days I was asked why a certain database field (CreditCount) that appeared to only need integer data was in fact a string. This field will eventually contain a character code. I should have been clearer. Not with a comment, mind you, but perhaps by changing the field name: CreditCountOrCode. Or, even better, making CreditCount numeric and adding a second field to handle the character code. If I had not still been on the project, someone likely would have changed it to an integer only to discover the reason in a few weeks or months from now and have to change it back. The later in the development cycle that you make fundamental changes, the more expensive it gets. No one wants that.


I came across this error today while deploying some SSRS reports to a server using the SSDT BI component for Visual Studio.

The path of the item ‘/DataSources//Database’ is not valid. The full path must be less than 260 characters long; other
restrictions apply. If the report server is in native mode, the path must start with slash.

I made the mistake of googling just the error message from the VS Error List window. That did not help. However, upon closer inspection of the Output window, it became clear that it was not the data source itself that was causing the problem, but one of its dependencies: a dataset.

I double-clicked the dataset in question, clicked ‘OK’ on the Shared Dataset Properties window, rebuilt, and the problem disappeared. There must have been something in the dataset file that I had imported into my Report project that pointed to the wrong place for the data source.


Learning to delegate is one of those things that you don’t really need to do much at the beginning of your career. And since it’s not (rarely?) taught in school, it’s something you largely have to develop on your own if you aren’t a natural delegater. (Incidentally, that would make a great name for a tasty alligator dish.)

If you’re good at what you do, delegating that work is HARD. How can I give this task to someone else when I know I can do it better, more quickly, or more to my exacting standards? It often feels like it would take as long to explain how to do it and support the person than it would take to do it myself.

Or would it?

If you’re anything like me, you probably do one of two things that sabotage your ability to delegate: you underestimate how long it will take to do something, or underestimate how capable your coworkers are.

I have been focusing heavily lately on delegation. In the project I’m currently involved in, I have done a large chunk of the ‘heavy lifting’ tasks. With deadlines and pressures, this is not practical. Instead, lately, I have been tending to ‘prime’ these tasks: clarifying and preparing things that need to be done so that someone else can take on some of the burden. Then I can evaluate the work of others, assist with remediation, and spend more time helping to plan, estimate, and prime other tasks. Not only does this help relieve some of the burden on me, but giving stretch tasks to others and then providing feedback/evaluation of their work helps them improve their skills. Wins all around.


I spent much of the past few days fixing a bug in some database access code that I wrote last year. Up until now, that code had caused very few problems, and I was quite proud of it. (I still am, in spite of this bug.)

In this case, I was losing database records that linked parent entities to children, but only in a circumstance where an entity with a list of child entities was created, saved, loaded, modified and then saved again. The lazy loading prevented the child entities from loading, as it was supposed to, but upon save, I was erasing all linking records, and then because the children weren’t loaded, skipping the writing part.

Once I identified the problem, I wrote a failing test case, fixed the original code, and confirmed the test passed. But here’s the rub: two new tests began to fail! After questioning whether I really had the correct solution to the original bug, and I wasn’t hallucinating, I began to investigate these failures. It was then that I discovered what had been happening: my code was *depending* on that bug. I had to fix that code too.



At my workplace, zedIT, our development team has been holding a quarterly half-day seminar session for the past few years. It’s an opportunity for us to get together and talk about what we are doing on our respective projects, or what we have learned outside work in our own career/professional development. In a distributed work environment where the developers are often allocated to separate projects, it’s also a rare opportunity to network and socialize. I never* miss it.

Today I ran the session for the first time. (I took over the reins a few months ago.) In addition, I gave a talk about an algorithm that I created in a project I am working on. The talk went fairly well, although I still need to polish my public speaking skills. Maybe if I had finished the talk more than 12 hours before I gave it, I might have had time to practice!

The other talks covered topics such as Microsoft Dynamics AX, Communications in Change Management, Browser Local Storage and NoSQL. It’s great to be able to take work time to learn about things that we would otherwise have to do on our own, which is often hard to do with the busy lives we lead these days.

I expect I’ll run the community for at least a couple of years, depending on when and whether there is someone else interested in taking it over.

* And now that I am in charge of it, it will never be scheduled when I’m on vacation!


Last night I had a dream that I was performing a code review for someone.

Keep in mind that browsers like Chrome, Firefox and others use an integer to represent this, but Internet Explorer and a browser whose logo looks like yellow and black lego blocks use a value that is specific to Windows. This used to be ok until that bastard James Franco messed it all up. Now we have to deal with the fallout. At any rate, just keep it in the back of your mind. I drunk.

I’m not sure if the dream was weirder, or if the fact that I was dreaming about code reviews is weirder. (Ok, I do know which is weirder!)

Nowhere that I have worked has ever had any kind of formal code review process. Usually the directive from management is something like ‘do code reviews’. As you can imagine, the quality of the code reviews that are then performed varies wildly. The most basic code review often only finds either the very obvious problems, or results in a reviewer making comments on things of minimal importance like style. If a developer makes obvious mistakes repeatedly, your problem isn’t solvable with code reviews.

I have also run into very in depth reviews. One reviewer in particular that I worked with took great pains to analyze what was written, and give a detailed and useful review. It was as if this person felt that he had as much of an investment in the code working correctly as I did, even though there was no mandate from management to do that. (He rightly rejected my fix because it was a bandage solution instead of addressing the underlying problem.) This reviewer had a tendency to initially analyze the work on his or her own, with no input from the original developer unless necessary. This helps test how easily the code is understood and remove any tendency for the reviewer to be gentler than necessary to stroke ego. After analysis is complete, the reviewer should work together with the developer to explain the analysis and where improvements are needed.

A very basic level of review should exist in any project. This will help prevent the most egregious problems from making it into the code base. Ideally, both the developer and the reviewer should have roughly the same stake in quality and correctness. This does not happen easily without organizational intervention. The goal for an organization in doing code reviews is primarily to improve code quality, but code reviews can dramatically and quickly help improve developers’ skills, which in turn, of course, help the organization. My advice: establish a code review policy, enforce it at the project or organization level, and help ensure that developers understand it’s about improving quality and not about criticizing work, and by embracing it, even the best developers can improve their skills.


For years I’ve been in the camp that optimization of software should come towards the end of a project. Build the software, profile it, then fix any outlandish problems. And that has largely worked fine. I tend to write the code for projects in which maintainability and simplicity outweigh performance. Part of my reasoning, too, has been because it’s often hard to tell where the performance problems lie until you take a measurement.

And that’s largely still true. But I’ve gradually come to push more in the direction of writing efficient code first. There are a lot of ways to do this, and once they become second nature, the effect it has on your ability to deliver should be minimal, while at the same time, your code will be, even if just a small amount, more efficient than it otherwise would.

Some of these methods include taking iteration-independent calculations outside of loops, choosing the smallest possible data type, filtering lists as early as possible (in the database if you can), reducing the amount of data delivered by web services, designing web services to be more coarse-grained instead of fine-grained, caching database access of things that will be accessed frequently, and perhaps even using fewer mutable objects. I’m sure you can think of many more. Some of these things a smart compiler will probably do for you, but they are good habits to be in nonetheless, particularly if you happen to not be using a smart compiler, or don’t know exactly how much optimization your compiler does.

All of this said, you can’t escape the profiling if you are experiencing performance problems. If nothing else, it will teach you about how to help avoid similar problems in the future.