October 2009 Blog Posts
IT Courage

A not uncommon situation occurs, especially in larger organizations, where a department ‘inherits’ an already existing application or system.  This can occur because of a reorganization or because of a recognition that the system needs a better home, or for other reasons.

Sometimes when this occurs, the inheriting group discovers that things are much worse than it seemed.  Problems have been swept under the rug, common software development practices haven’t been followed, production issues occur on a nearly daily basis, etc. etc. etc.

A very rare reaction to this is for the head of the inheriting group to put their foot down.  No more active development, no more adding functionality.  Instead, the situation must be stabilized, with no more daily production issues.

It’s a common sense decision, but it is one that can be hard to make.  The person making the decision has to have some internal credibility already, or be willing to put their credibility on the line.  Since there are so many problems, the end users probably have little confidence in the system anyway, so it is hard for the situation to get any worse, but there can be a perception along the lines of “The system already doesn’t work very well, and now we aren’t even getting any new features.” 

I’ve seen this occur a couple of times the last few years.  The first time, it worked out quite well.  Daily problems became every other day problems became weekly problems became monthly problems.  End users started to gain confidence that the software would actually work.  As new development started ramping up, it was met with less skepticism since confidence had grown.

To the extent that it is possible, fixing endemic daily production issues should take precedence over new functionality.

posted @ Friday, October 30, 2009 8:55 PM | Feedback (0)
Hockey Announcing Brilliance

Because I was on the East Coast for a wedding, I was not able to watch either of the first two games of the Pens this year.

So, naturally, I got to watch the Pens hook, trip and slash their way to a 3-0 loss to the Phoenix/Saskatoon/Hamilton/Kansas City/Las Vegas Coyotes in a really pathetic effort.  Malkin appears to have been motivated out of jealousy of Ovechkin’s 17 goals (or whatever) in 3 games by deciding to triple that output in penalty minutes.

Anyway, the otherwise dismal game was ‘enlightened’ with this gem by Pens’ lead announcer Paul Steigerwald:

“The Penguins are the sort of team that thrives on scoring goals.”

Uh, right.  As opposed to all those other teams that thrive on things other than scoring goals.

posted @ Thursday, October 08, 2009 7:19 PM | Feedback (0)
Awful Announcing

I had no idea this site existed.  Of particular enjoyment are the weekly Pammy awards.

posted @ Monday, October 05, 2009 2:40 PM | Feedback (0)
Those Wacky Software Craftsmen

Minor update: Scott addressed the attribution thing in this post, so retracting those comments.

Recently, Scott C Reynolds has been writing a couple of posts about….well, it’s hard to tell exactly what they are really about, but at least in his mind they are apparently about quality and professionalism and maintainability and the usual laundry list of things that ‘software craftsmen’ like to pontificate about.  As is often the case, there’s a nice mixture of well thought out insight, good advice, misguided idealism, hilariously misplaced snideness, and outright ignorance.  But it makes for some fun reads.

Don’t put words in my mouth, I’m too busy using it insulting people

The first post is his response to Joel Spolsky’s Duct-Programmer.  He begins by telling us:

I suppose it's time for the obligatory weigh-in on the latest bit o' reckless software advice from Joel Spolsky on the merits of the "Duct Tape Programmer".  I think being a duct tape programmer is a bit like being an alcoholic.

That’s a great start.  Joel is reckless, and he compares being a duct tape programmer with being an alcoholic.  Clearly, we have a calm, considered analysis coming up.  It immediately gets better:

I don't want to get too deep in the weeds on Joel's article, because the simple fact is that it doesn't warrant as much discussion as it's getting.

So, being a duct tape programmer is like being an alcoholic, yet, the article isn’t worth discussing.  Nice.  It gets better still:

There's a major problem in this industry

Let’s digress a bit.  A key theme of the craftsmanship movement is to talk about how there are major problems in the industry.  This is already dangerous territory, as the problems in the industry, if they exist, exist mainly not because of problems with programmers, but with the business of software development, and mainly on the business side.

And yet, Mr. Reynolds immediately turns to true insights:

Every product is different, every organization is different, and the needs of each varies wildly. Therefore it's impossible to prescribe one action over another free of context. The second side of that same coin is that the vast majority of people taking this sort of context free advice don't recognize this lack of context and run with it because some hero they worship said it. Then you get people that say things like "I don't want to write tests because Jeff Atwood and Joel Spolsky don't" or "I just want to code all night in a cave and 'get shit done' because that's what Joel said is valuable to business". This is a major problem.

The first part is exactly right.  What counts as the right software practices depends on context, and he nails this.  He is also right in that there is a pragmatic rhetorical reality that there will be those who misread Joel’s article and think that they can simply dismiss doing any sort of testing, be it POUT (plain ol’ unit testing), TDD, or more.  This is, unfortunately, an accurate assessment.

Just as unfortunate, SCR decides to take the discussion away from these insights and back towards denigrating others:

But let's be real. The vast majority of software development out there is on the more "mundane" know...the ones that run the world, rather than the fancy Web 2.0 products. Do you want a duct tape programmer writing the software that controls your bank, or the lab equipment processing your mother's biopsy, or your insurance company's claims system or the air traffic control systems?

As I mentioned in the comments (and more on those later, as there’s some real fun there), the fact of the matter is that duct tape programmers probably have written the software that controls your bank, etc.  Whether this is a good thing or not is another question, but it is probably a fact.  By contrasting ‘being real’ with what actually is real, SCR continues the implicit rejection of duct tape programming (DTP from now on), for no apparent reason, other than he doesn’t like it, or misunderstands it.

Yet, once again, he states the truth:

Being for a maintainable codebase doesn't mean being against shipping. Being for code quality doesn't mean being for cleverness or complexity for the sake of cool (quite often it means the opposite).

Absolutely.  As I mentioned in my post about the topic, Joel seems to contrast DTP with astronaut architecture, as if that is the correct comparison.  It isn’t.  People who practice unit testing of whatever sort tend to be against astronaut architecture as much as anyone.  However, what he says about TDD is problematic:

Getting started on TDD will be slow at first, but the payoff is huge.

This, of course, isn’t true, if meant as a categorical statement.  “[I]t's impossible to prescribe one action over another free of context.”  Yet, the payoff with TDD *is* huge.  As anyone who has practiced TDD will tell you, this isn’t necessarily true.  Practicing TDD can be a disaster.  Tests that are brittle fail on refactoring, which can lead to a total lack in confidence in unit testing in general.  This is something that practitioners of TDD say themselves.  Moreover, practitioners of BDD-style development have critiques of TDD at a more general level.

Using the principle of charity, one might think that Mr. Reynolds simply mis-states what he means to say, pushed in that direction because of how Joel’s article might be read.  But, he immediately undercuts the principle of charity with his closing remarks:

Matt Hinze said it best when he said "...never take software advice from a bug tracking system salesman".

Oh and let's not forget how bad Netscape's browser ultimately became, and what a bloated piece of garbage it was by the time it died. Guess all that duct tape caught up with them.

Never mind that no one cares what Matt Hinze says (though what he says is funny), and never mind that SCR doesn’t appear to know that the history of Netscape’s browser has nothing to do with DTP.  Mr. Reynolds seems to think that he has the position to make claims about Joel that he clearly does not have, and this follows the rest of the post.  Joel clearly doesn’t know anything about software or software advice.

This is, obviously, total garbage.  Whatever one might think about Joel, he has a history and a established reputation, and the silly barbs of some blogger mean next to nothing in comparison.

Now, some fun stuff happened in the comments.  I’ll get to most of them towards the end but one theme arose that deserves special attention.

The Hypocrisy of Software Craftsmen

Caught in the ‘crossfire’ of a comment that I made and SCR’s odd opinions, another commenter named ‘Scott’ had a thing or two to say, and made the ‘mistake’ of thinking there was something in what I had to say and got this response:

jdn is a useless troll, you just may be lacking the historical context to know that. When he says something that merits response, I'll do so.

As to the rest of your comment, I'll make you a deal. You're fairly anonymous right now, I don't know you, and I honestly can't tell if you're just trying to push my buttons or if you're asking honest questions.

If it's the latter, I'm glad to respond. Probably in a new blog post.

One of the things that SCR seemed to be angry with me about (and more on this later) was that I ‘called into question’ his opinion, as ‘just’ being a LosTechies blogger.  And yet, he responded to others in the same way that is so common from cowards who claim to be craftsmen: it doesn’t matter if you have good points to make or not, I’m only going to speak to you if you prove to me that you are worthy to be spoken to.

Um, this was my exact point of asking why anyone should listen to what SCR had to say, given that Joel has street credibility and SCR is just another blogger.

Back when we were inventing the internet along with Al Gore, we had this thing called USENET.  Though there were moderated newsgroups, for the most part, anyone could talk about what they wanted to talk about.  Anyone could respond to anyone else.  It was easy to call someone who disagreed with you a troll, but to do so generally made it clear that you had nothing valuable to say in response.

Some people have asked whether twitter has killed blogging, but blogging pretty clearly killed USENET.  I don’t really know of anyone that uses USENET anymore.

What some bloggers have resorted to is to refuse to engage in conversation when confronted with reasonable arguments against them, by resorting to the whole ‘you haven’t proven yourself to me yet’ gambit.  Lame, lame, lame.

If you have a blog, and someone responds, unless they are insulting your heritage or something, show some guts and stand up.  ‘Craftsmen’ like SCR who totally misread a post and then complain that their comments have been misread, and otherwise refuse to stand up and defend what they actually say are cowards, pure and simple (moment of silence for Cronan…………..thank you).

It has to be good because it is new

In his second post, SCR decides to steal without attribution the whole ‘hand-washing reduced maternal death, and somehow this applies to software development’ meme, and having stolen that, quotes a number of comments including one of my comments from the previous post:

Although the numbers are changing, the VAST majority of successful, well-written software wasn't developed using TDD.

and comes up with the following totally illogical conclusion:

These comments pretty fairly represent things I hear an awful lot out of some community segments, and it boils down to "I don't need to learn or apply [x] because we've been getting things done without it."

Who knows how he comes to this conclusion.  I’ve never said anything like that, and I don’t think you could possibly mis-read Joel to think he says something like that.  It is a fact that the vast majority of successful, well-written software wasn’t developed using TDD, but this doesn’t mean that TDD is therefore bad.  One *should* wonder about this, and wonder why this is, and thus view with skepticism anyone who claims that TDD is required for developing well-written software, which SCR doesn’t do explicitly, but comes pretty close to doing:

In my previous post, I said that I believe that certain practices have a lot of value and can lead to major improvements in the way I construct software. I believe this because I have taken the time and made the genuine effort to experiment and measure results. If you have not done so, then your opinion on the matter is irrelevant.

How precisely did he experiment and measure results?  Who knows, he doesn’t really say.  On the principle of charity, one should give him the benefit of doubt, except that he’s already thrown that away by ignorantly insulting Joel’s experience.

He continues the silliness with this:

If you insist on dismissing anything someone recommends because they don't have the data to prove beyond a shadow of a doubt that a given practice is globally applicable and will result in improved outcomes in all cases, then I will insist on dismissing you unless you have the data to prove the opposite. And I'm sorry kids, but "plenty of software was built without [some practice]" just doesn't cut it as proof, so kindly take that argument elsewhere.

No one that I know of says anything about the global applicability of given practices, *except* for some who advocate the practices he prefers.  Moreover, he again ignores the rational skepticism that people might have about practices that have not been practiced, and yet produced well-written software.  The rational person would want to know why this might be.

He finishes the silliness with this beauty:

I'll come right out and say it, if you have no interest in improving what you do, and are fully content to maintain the status quo and shoot down every idea that can't be mathematically proven to be globally applicable, you are lazy, unprofessional, and have no place in this business.

Ah, the call of the craftsman.  If you don’t follow what I think is right, you are lazy, unprofessional, and have no place in the business.  Uh, no.  People who have no credibility who think they have the position or the right to call others unprofessional should learn some humility, gain some knowledge, and in the meantime, shut the fuck up.

Yes, Virginia, I do have a PhD.  What about it?

One of the funniest parts of the whole thing involves a reply to a comment that SCR made.  I don’t Twitter, but I was told that he actually debated whether to post this comment, apparently thinking it was ‘devastating’ or something.  Because it is so hilarious, I post the comment in its entirety:


I didn't answer your question because it wasn't directed at me. It was clearly directed at somebody that you heard say things that you are misattributing to me. I don't intend to play your game.

If this post were about TDD (it isn't), and if I said that TDD is the only way to develop good software (I didn't), and if I said that only bad programmers don't use TDD (I didn't), and if I said that I was better than Zawinski (I didn't) then these kinds of comments *may* be warranted.

As it stands, I refuse to engage in a debate with someone who, despite having 15 PhDs or whatever, doesn't seem to have leveled up his reading comprehension skill very much.  Either that, or you're a useless troll. You either intentionally are trying to pick a fight about things I didn't say in the post, or, you didn't read and understand the post.  Your pick. Stupid? Or Troll?  What's it gonna be? Which one fits you better? It's one or the other. Either you got those PhDs by mail order, or you're a troll.

Personally I don't care which one it is. Come back when you grow up and want to engage in real discussion. At present, however, your past interactions with myself and others, and your comments here, give me no reason to treat you as anything but a troll...or...I guess if it turns out you're not really that bright after all,  I'll feel a little bad for being so mean. But don't worry, I won't spread it around that your PhDs came from a Cracker Jacks prize pouch.

I haven’t the slightest idea how the whole PhD thing came up.  I know that I’ve mentioned it twice online, once when Uncle Fester was questioning who I was, and once when David Anderson was questioning who I was.  As I mentioned above, cowards ask for identification before engaging in debate, but that’s okay.

But, yes, I do have a PhD.  Achieved at the age of 25 (when some were still fighting through community college and trying to decide what their major should be, not that there is anything wrong with that).  It was achieved in Philosophy, a major portion of which involves learning the basics of logic and rational argument.  It is nearly impossible to have truly logical arguments in philosophical journals, so the fact that it is even more difficult online is understandable. 

What someone like SCR really seems incapable of doing is being challenged on his core beliefs, especially when he wraps those core beliefs in ignorant insults of people who’ve accomplished much more than he has (I’m thinking of Joel here, not myself).  Which is fine.  I’m sure in his echo chamber, that goes over well.

And yet…Mr. Reynolds and I apparently agree

In a comment to his first post, someone named ‘Josh’ says, in part:

I've done TDD, waterfall, no spec, post card spec, cowboy coding, etc. All done through classic asp up to .net 3.5. Classic ASP was just horrible to code in. It worked though, and got a job done. There was even times when changes were done on a production box! Would I ever do that again, yes. The 6 pages for my dad's website doesn't need TDD, a full documented spec. Would I do that for the project I'm working on right now, heck no!

To which SCR responded:

That's a fair and pragmatic view

Well, there you go.  I agree with that entirely.

Given my choice, would I work on a software project where I couldn’t create a significant set of tests that covered the work I was doing?  Hell no, for reasons I’ve mentioned in previous posts.  Especially when you can create automated integration tests, tests at the business specification level allow the non-DTP a level of safety and assurance that almost (note I said, almost) guarantees an increase in quality, at almost (note I said, almost) no cost.  Why wouldn’t any sane developer want to do this?

Being a ‘craftsman’ can be done without pretending that calling oneself one, and denigrating others that don’t call themselves one, makes one so.

posted @ Saturday, October 03, 2009 8:38 PM | Feedback (1)