Business
The latest .Net Rocks podcast was from a panel at TechEd 2008 (that I sadly missed while there). Richard Campbell was the moderator and the topic was Software Quality. It was a good, if somewhat one-sided discussion and I recommend giving it a listen if you are so inclined. I particularly liked Billy Hollis' perspective on quality because it was a perspective that was grounded in both reality and sound business principles. He kept bringing up quality in terms of trade-offs and the others kept trying to waltz around those comments with a more absolutist, almost dogmatic, vision...
I thought I'd take a shot at introducing myself here as suggested by Jay and maybe dispel any pretense at being a thinker, heady or no. Frankly, it's probably long past time that I put together some kind of background post about myself if only to give those who disagree with me a way to discount my arguments out of hand.
I suspect this'll be long as I do go on sometimes. You can skip to a recent, similar post if you only want the heart of my current situation.
Street Cred
I've been playing with computers in one way or another...
Reading the beginning of Joel’s second section of his talk at Yale clarified one reason I find myself so at odds with much of the hard-core Dependency Injection crowd (has Joel really achieved the level of fame that we can dispense with using his last name as Phil Haack suggests? Did you know who I meant right off?). Anyway, I am an in-house developer in a small company and that has a huge effect on my architectural decisions.
In-house Development
I described it a couple of months ago as simply "small company development", but Joel’s right that the more significant aspect...
I typically work with small companies who need to customize software to fit their business practices. A lot of companies have critical competitive advantages embedded in the way that they do things and need to ensure that their software doesn’t get in their way. That typically means that I deal with specific vertical markets (either at the vendor or client level) and dance with 500lb. gorillas to make things work the way companies expect them to. It’s business programming in the trenches and can be nasty, brutish, and, well, not short so much as constrained.
The Typical Battlefield
This is the...
I found Scott Adams' (yes, that Scott Adams) blog post today about The Power of Choice interesting. Particularly at the end where he says this:
The next time your mate or co-worker is butting heads with you over a decision, recast the situation as their choice.
For example, let’s say you favor Option A, and someone else wants Option B for reasons that seem to you irrational. You are at an impasse. Change the question to this:
“Okay, do you want Option A with this risk, or do you want Option B with this other risk? It’s your call.”
When...
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...
I said yesterday that
The skill sets [of developers and QA people] aren't simply unrelated—they are, to an extent, opposed.
I think that deserves some explanation because for some reason this is not obvious even to people in IT.
The reason that developers and testers require fundamentally different skill sets is that they have fundamentally different responsibilities. What it comes down to is that it is a developer's job to make software work and it is a testers job to make "working" software break. In fact, I knew I had found the right QA Manager for XanGo when one of the first...
I wrote last month about winning arguments in IT. Earlier this week, Phil Haack asked a question (through Twitter) about things he could do to help convince a company to create an in-house QA department. Well, it turns out that I did exactly that at XanGo—successfully pushed for and oversaw the installation of an in-house QA department. I thought it might be a useful follow-up to the previous post to use this as an example of how I "won" that argument.
Concentrate on What is Best for the Company
This is the key, the whole key and nothing but the key to winning...
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...