Don't know if April brings out the esoteric nature in people or if it's just the tweaks I made to my blogroll but I've been reading a lot of "peripheral" posts lately. That is, posts related more to the art of software development rather than the science. A lot of that comes from the addition of Mike Griffiths' Leading Answers blog which is a gold mine of information though I don't mind admitting that more than a few of the posts are over my head. After reading his top five software risks, along with Justice Gray's career security and Tim Heuer's avoidance tools, like my clients often say, one might wonder if I write software at all.

I do so like reading these posts for the same reason I took a Computer Ethics course back in university in the middle of my courses on graphics and assembly: you can't ignore the people factor in computer science. And this is kind of an underlying theme in any post/essay/book that strays from bits and bytes.

But I also get a sense that these topics preach to the choir a little. For example, one should get the team more involved in scheduling to help mitigate schedule slippage. That may not necessarily be common sense but put yourself in the (highly unlikely) position of someone who is in charge of a software project and the schedule starts slipping. What would your natural reaction be? I'd like to think mine would be to get the team together and hash things out, even without reading this post. It seems like the natural thing to do, not a revolutionary shift in project management.

I get the sense that most of the people I respect and follow online would do something similar. Maybe that's just the type of person I am and maybe that's just the type of person I gravitate toward. Or maybe the business culture has evolved to the point where openness with your team/client/shareholders is the natural reaction.

Or maybe I'm being naive in assuming that the majority of people would do it this way. And that's very likely given my overly optimistic nature.

Let's talk about Justice's career security. I'm sure there were a lot of heads nodding knowingly while people read that post. But I'll bet that all those bobble-heads were very bright people. People that don't necessarily need to worry about where their next paycheque comes from even when the price of oil drops to $3. These are people that will always be in demand and their advice will reflect that.

But as I've often said, you can't save everybody. There exist in this world people who are not particularly good at what they do, who don't want to better themselves, and who are in it merely for the paycheque at the end of the week. The problem is: are these people reading posts claiming you should involve users more in the software development process? Because they are the ones that should be.

The point is, I'll read The Pragmatic Programmer or Beyond Code and agree with pretty much everything. And a lot of it (I hope) is stuff I would normally do. But what about the people who *should* be reading it?

Or maybe I'm missing the point. I was listening to a podcast whose name escapes me (statistically speaking, probably Hanselminutes or DotNetRocks) where the speaker said this stuff wasn't really groundbreaking but that now you could use it to justify your actions to someone who doesn't know any better. E.g. Of course I'm going to starting soliciting advice from my team members when my schedule starts to shift. But if my boss starts railing on me for burdening them with these "petty problems", now I can point to a number of resources saying this is the thing to do. Alas, I'm not a huge fan of having to justify myself in such a manner because it's pretty easy to shoot down with other, more traditional literature.

I've kind of arrived at a point that makes it sound like I think I'm better than other people and that I should try to fix them. So I'll close off by clicking Undo and saying that I think the point isn't necessarily to overhaul someone else's perspective but to tweak your own. I.E. Rather than upgrading JoeCranky to version 2.0, just work on CodingHillbilly 1.2.5. That's where the value comes in. Sure, you may think a lot of it is common sense. But not all of it. And very often, the act of "codifying" this fuzzy aspect of software development helps you become more conscious of what you're doing.

Bah! Too many maybes. I'm going to write a QuickSort.