Development
There are 22 entries for the tag
Development
One of the things I am seeing less of lately is the understanding that reasonable people can and will disagree with one another—without either of them being any the less reasonable or intelligent for doing so. It seems to me that people become so invested with the “rightness” of their ideas that they deny the possibility that those who disagree with them may be equally intelligent and well-informed. You see it a lot in politics, but I think that this attitude has crept into development discussions as well. I saw a manifestation of this in action after a...
I’m on record as dissenting from some of the planks of the Alt.Net bandwagon. I question design for testability and have extended that to questioning what I consider to be the over-use of Dependency Injection (though I’ve also talked about using it successfully in a project that I believe warranted its use). Further, in my last post, I asked if the Alt.Net folks couldn’t expand their treatments of design principles to include contra-indications or fault points. I also decried those who actively stifle alternative viewpoints, though I left it vague about who I think might do so. Given...
Many of the interesting .Net bloggers are part of the Alt.Net crowd; evangelizing Dependency Injection, Design for Testability, Test Driven Development, SOLID design and other development practices that they find useful in their work. It doesn’t take long reading these blogs to pick up on what looks like an unforgiving attitude towards those who don’t use the latest acronyms in their software development. This acrimony is unfortunate because most often what is at the heart of those who question the standard Alt.Net toolset isn’t so much principle as it is context. A Fundamental Assumption Unfortunately, discussing...
And I’m okay. Indeed, last week saw a payoff for one of those hygiene things you do because you know that you “should”. A Logging Story Allow me to share what happened (feel free to skip this section). We receive orders from a number of different sources. In addition to EDI, we have spreadsheets, flat-files, and we even originate a few ourselves under Vendor Managed Inventory (VMI) agreements. One of the things we’ve done recently is create a single “process pipeline” such that once orders enter the pipeline, their processing from that point forward...
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...
You might say that I’ve had issues with Dependency Injection in the past. Well, with all the things I’ve learned not to do, I thought I’d go into a case where I’m considering dependency injection because it looks like it might be a good fit. Project Background Like many (most?) developers, I’ve been involved for many years in a particular vertical market. Like most, my involvement in that vertical market includes acquiring a substantial amount of very specific domain knowledge. I’m sometimes reluctant to admit it, but I spent a good decade and more of my career...
Aaron Lerch talks a bit about what it takes to be a technical manager. He enumerates five characteristics that he feels are essential for a technical manager (personally, I think that they are better classified as skills because they’re learnable and improvable). Here’s his five:
Communication
Technical Savvy
Organizational Skills
Priorities
Humility
It’s a good list for the good times, I think. As long as things run more or less smoothly, a manager with those traits will be in good...
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...
Because Unit Testing is the plain-Jane progenitor of Test Driven Development, it's kind of unfair that it doesn't have an acronym of its own. After all, it's hard to get programmer types to pay attention if they don't have some obscure jargon to bandy about. UT is too awkward, besides being a state abbreviation in the U.S., so for this post (and, if it catches on, future posts as well) I'll borrow from the telco folks and call unit testing Plain Old Unit Testing.
The Best of all Possible Worlds
Part of my problem with TDD has been that it claims...
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....
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...
In one of his characteristically long essays, Bill Whittle expounded at length on the genius of John Boyd. The essay is political and not necessary to understand my point, so follow the link at your own risk.
At any rate, Boyd proved a tactical theory of aerial combat by repeatedly winning a challenge to the best Air Force pilots in Nevada. The challenger would start by having Boyd in a perfect kill position at thirty thousand feet over the Nevada desert. Once the challenger yelled "Fight’s on!", Boyd had 40 seconds to reverse their positions.
Winning that challenge repeatedly and consistently...
Anyone who has been forced to deal with EDI X12 documents knows that they are a royal pain. Each document has tons of fields—enough for any reasonable use for any reasonable organization. Having so many defined fields is actually its biggest liability. It means that every organization that uses EDI X12 pretty much has to decide what fields are significant for them. That means, for example, that an 850 document is functionally different for Nordstroms than it is for, say, Wal-Mart.
As a result, there’s a significant market for people who can map EDI documents. Most of them are service...
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...
In many companies developer career progression is deceptively straight-forward; Jr. Programmer, Programmer, Sr. Programmer, Team Lead, Architect, Sr. Architect, Bob (Bob being the semi-mythical entity referred to in obscure comments, worshipped by now-extinct aboriginal tribes, and rumored to haunt the sub-sub-basement).
The differentiation between these positions starts off with how much you know. A Sr. Programmer is a Jr. Programmer who knows his tools inside and out and can complete assigned tasks quickly and without a lot of supervision. Around Team Lead time, however, progression stops being about what you know and starts revolving around your ability to choose wisely...
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...
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...
The trend towards increasing security introduces a number of intricacies for medium-sized business software shops using Active Directory Domains. An internal domain with more than a dozen workstations can introduce issues that are old hat for larger shops, but way beyond anything a small business will have to deal with. I ran into one such issue recently when I decided it'd be a cool thing for one of my apps to actually run from the network.
The Problem
The first sign I had a problem was when a module that worked fine locally threw a "System.Security.SecurityException" when run from a network share....