Rant
One of the things that irks me when discussing certain technical topics is a tendency towards boosterism that can hinder, or even halt, deeper evaluation and discussion. Some topics, tools, or practices arrive with a divine imprimatur of authority that is hard to resist. Since I believe in being personally responsible for the software development I undertake, I sometimes find myself exploring murky territory that seems like it should be better mapped. The latest of these pre-hallowed principles is Test-driven Development.
What comes across as a casual assumption of superiority gets my hackles up. I'll show what I mean using...
The discussion spawned from my TDD post has been interesting to me. I've enjoyed the comments by Phil on his post and by him and others on my own. I'm particularly flattered that one of the authors of the original study dropped by. I disagree with some of his points, but this isn't where I want to address them. Instead, I want to examine the discussion itself because this is definitely something that we as a software development community could be better at.
The Report
First, I want to emphasize something that I could have made clearer in my original post....
Dependency Injection is a design pattern used to abstract a provider from the class using it. Specifically, the calling class assumes responsibility for managing the provider instead of the class being called. Data access is a classic example of a provider that can be injected into classes that use it. If you decide to implement the DI pattern in a data access project, the most common method of doing so is to add an interface parameter on the constructor of each class that needs data access.
A C# Example
A class that accesses data might look like this (if it were programmed...
When I go over the tools that I use for software development, it's not actually true (as a friend recently accused) that "if it isn't produced by Microsoft, Jacob won't use it." Still, while I don't hesitate to use tools not produced by Microsoft, there's no denying that the majority of what I use day-to-day has its origins in Redmond, Washington. The question Microsoft's detractors need to be asking themselves is why that might be the case.
It's Not the Hot and Cold Running Babes
Because here's the cold, hard truth: there's not a thing in it for me to continue using...
There's a reason that my personal blog is named The Rabid Paladin—I form opinions easily and express them strongly, even as I attempt to maintain an even keel through my sense of integrity. What this means is that on those occasions when I enter an argument with the purpose of informing and/or convincing others, I try to remain open to valid points from other perspectives and the possibility that I might be wrong.
Letting Bias Show
Too often, people arguing their case will paint alternatives in as bad a light as possible—perhaps believing that their misrepresentations make their arguments stronger. The...
I've been considering this post for a while now, but have been afraid to actually write it. So here's the thing: I've noticed that most of those who talk about how evil Microsoft is don't bother supporting that assertion. They tend to assume the rightness of their position and hence the wrongness of whatever it is that Microsoft has done. Microsoft stifles technology! Microsoft is a monopoly! Microsoft engages in unfair business practices!
Do they really?
No Consumers Were Harmed in Making This Software
There's a couple of problems with the whole monopoly thing. For one, at least in the U.S., being...
Steve Harman had a post back at the beginning of the month about stuff you'd tell a young developer. It's a reaction to a similar piece by Jeremy Allison. It's an interesting topic, so I thought I'd waste a few pixels on it myself.
If it's not what you love, don't do it
I wouldn't generalize this to other fields, but for software development, I think this is a good thing to keep in mind. A lot has been made in the past by career counselors and other gurus about "finding your bliss" or similar nonsense. I think that's mostly a crock. You...
Have you ever found yourself in a situation where you know what's the best thing to do, but are unable to convince anyone else that you are right? Developers know that even simple problems have more than one solution. Developers who have worked on a team of more than one have probably been in a situation where they just knew that the team was heading in the wrong direction and that they had a solution that was more elegant, easier to program, and better to maintain.
Higher profile developers often find themselves trying to explain their solutions to non-technical people...