I take it all back! Send me your money!

Welcome back. This comment is actually about your essay on Refactoring but that page doesn't have it's own comments so I'll put it here.

It seems to me that you characterise Refactoring as turning bad code into good code. I think that's missing half the story. Almost all the refactorings are reversible and have opposites. The reason is that good and bad are subjective and are applied to a context. If you applied every refactoring in the book, you'd just be back where you started.

Refactoring is also about making code easier to change. Some code may be good in its original context, but adding some new feature would be easier if it were factored a different way. The refactored code may then be bad in its original context. But that doesn't matter at this point since the purpose isn't to improve the code, but to make it easier to change into the new context. The advantage of automation is in reducing the chances of human error while making changes.

Once you have changed the code (which should be easier due to the refactoring) you can then set about improving the structure for the new context. Again, the automation reduces the chances of introducing an error.

In summary, you take a one step process "changing a working program" and turn it into a 3 step process "refactor", "change", "refactor". Much of the gain comes from the ability to automate the refactoring steps and thus reduce the chances for errors.

One reason this may be less of an issue for a language like Ruby, would be if most changes are easy to make anyway. That is, where code is equally good in the original and new contexts, refactoring is redundant.

So what happened to Wyvern? Cabochon.com has been unavailable for a long time.

I love Emacs now. Because of you. Why don't you give us the whole emacs package? ttest, ekeys and stuff! Please!

"People accuse me of being long-winded, but it's not often that breaking short wind, amusing as it can be, has any real long-term effect."

Yes, I have noticed this many times among your commenters. It always reminds me of a conversation between Mozart and the emperor of Austria (among others) in the movie Amadeus:

Emperor Joseph II: "My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect."
Mozart: "Which few did you have in mind, Majesty?"

'Nuff said.

Hmm, Steve, Paul Graham and Joel Spolsky all seem to have the same prescription for IT nirvana: Be one of the very best, only work with the very best, only hire the very best.

These are all great ideas, but have absolutely nothing to teach us in terms of how to actually do things. It should be obvious that great people in a poor system will outperform poor people in a great system. In fact great people don't need a "system". Systems exist to quantify and make predictable the efforts of average people. And most people are average.

So I think the main point Steve made here could be summed up as, "Great people do great work, and they do it without needing or wanting a formal process."

Don't get me wrong, I wish more people truly valued the people in their organization rather than just paying lip service to it. I think if you can get the right people working on a problem, you don't need to impose so much formal process. But wrapping that advice up in a slam against a specific process that happens to have some current buzz isn't meaningful or useful.

Stevey, could you comment on why you think OCaml isn't fit for server-side usage?

Steve, I think your comments about Agile development are both interesting and wrong.

Every complaint you've listed about Agile development is can be applied to other development styles.

I worked at a place that thought CMM5 was the only way to develop software. We were required to document every function in our code, along with every parameter. Once coding started changing the spec required at minimum of 3 meetings that took over a week to occur.

The net effect was enormously long functions, massive duplication of code and a project that was eventually cancelled.

Coming from that world the ideas of Agile development are a breath of fresh air. I think you need to give the Agile guys a break. Sure Agile development isn't optimal for creating original software. But, considering the sorts of crap methodologies that were about before they showed up, the things they've come up with aren't so bad.

What you have been complaining about is stupid managers, religious zealots, and the really scary mix of the two. But this isn't an Agile thing at all. Agile development just happens to be the current fad among irresponsible managers.

Regarding the zealots, if you've come from a shop that has older heavyweight development processes, Switching to Agile can be an almost religious experience and engenders the same sort of devotion and misguided zealotry.

All your contrasting of Agile to Google development practices was to advocate an even lighter weight development process.

What Agile development and what the consultants are all about is helping management loosen up and let developers do their work. I understand that coming from someplace like Google, Agile stuff seems really heavyweight. But coming from places that are truly heavyweight, Agile development is amazing. What Agile does really well is let the old guard managers have their beloved predictability while saddling the developers with less process related crap.

Stand up meetings seem really wonderful when they are contrasted with hours long status report meetings. Stories are wonderful ways to capture what is different about this app from the five that are almost exactly the same you've done before. And Stories, don't require hundred page long Word documents.

The main complaint I have with Agile development is that it's current popularity has made it become almost meaningless. Much like "object-oriented" lost meaning in the 1990s.

But the ideas that drove Agile are really valuable. Ultimately they are about reducing the "ceremony" in heavy weight development processes. And doing that in a way that lets management feel in control.

Your complaints were about the "ceremony" that agile leaves in place, but fail to acknowledge the "ceremonies" they replaced.

I completely agree with everything you've said about the Agile camp. I'd like to talk about the discipline of Software Engineering in general.
I've been involved in one or more aspects of software life cycle for more than 10 years now and still haven't figured out where the Engineering in software development really comes from. Software Engineering papers, magazines and research journals mostly talk about process and management. Granted that's one aspect of engineering, but Engineering it is not. Reading journals like IEEE Software Engineering I'm convinced that there are legions of researches trying to figure out new ways of winning millions of dollars of grant money. What easier way than to focus on this "soft side" of software development? This is where I compare these researchers to the Agile folks. They have definitely found a much easier path to fame and/or riches.
I must admit I'm not and have never been a practicing professional engineer. However, I did major in both mechanical engineering and computer science. One thing that becomes quite obvious to anyone familiar with both fields is that while engineering is very structured, formal and mathematical, computer science is not. Granted there is a level of mathematics involved in the analysis of algorithms, but that does not constitute the entire realm of CS. The lack of structure leaves a lot up to an individual's skill and intelligence level.
Can CS ever be structured and mathematical? There have been attempts with works around lambda calculus, formal methods, theorem proving etc. to make it so. So far these have pretty much had no adoption in the industry. I won't go into why I feel these have not been well received here. My experience has been that software development is an art whose success greatly depends on the skill level of individuals. Any attempts to quantify are bound to fail as we've seen with a number of approaches and procedures.

Damn you, Yegge!! You got me hooked on emacs, as well!

It's not all your fault - my company is all Linux and emacs talks to gcc and gives me the errors - and I didn't like kDevelop. My only wish for emacs is key bindings that match common software - you don't know how many times I have C-x C-s'd in MSDEV only to blow away a line of code.

I would love it if you would enlighten us with some of your emacs wisdom - I know there are books, but you've got alot of practical insight that I have already found valuable.

Oh, and because of you, I am looking into OCaml and LISP. Curse you for tempting me with the sweet, sweet fruit of knowledge!!

j,

Have you already read Effective Emacs from Steve?

J:

key bindings that match common software

XKeymacs is priceless!

All of what you have written that I have had the ability to read during my day is more than just a good, educational and entertaing read, but something anyone at any level of any company should read and give more than a passing thought upon.

As a manager, I have found that avoiding "Agile" for true agility is not only a good idea but it does, in fact, give the magical production gains that the "Agile" camps claim to give.

And in a moment of frivolity, I bestow upon you the title of IT ninja #2 (because I was given the #1 spot as part of my official job title years ago at a startup ISP).

Hi Steve,

It's an odd thing that you mention your blog cropping up from time to time. I first found your Amazon rants when I was Googling for some non-Emacs-related term (I was a vim user back then). At almost the same time, I found your Google blog, in an unrelated query. For quite a while I was reading both blogs at the same time, without realising they shared the same author. A wee bit later your blog appeared on slashdot. Just now I found your blog linked to from an Emacs page.

I keep on meaning to bookmark your blog, but I don't really see the point any more - I'm scheduled to stumble on your next rant in a few months time, through a random link from a random page listed in a random Google query.

All the best :-)
Colin Horne

Steve, I think it says a lot for you that people are still discussing Wyvern even now and waiting for it. I am one of the 50,000 (Ikasha, lvl 20 human)and have really enjoyed my time with the game. It's incredibly inventive and the community of people seems especially high quality for role playing games. Hope you get the game up and running soon.

Your line, "I could use a good marketing name for this longer-is-better phenomenon" caught my eye. I find on my blog, http://doxspot.blogspot.com, that my entries are longer than on most. That isn't my intention and I do value brevity, but the topics seem to require more. I essentially warn folks about it in my header. I do wonder how much longer-entry blogs inherently limit readers.

Dox O'Ryan
http://doxspot.blogspot.com/

Hey steve, AKA rhialto, hows it going. I too am one of the anxious 50,000 who are waiting and desperately going on everyday to the internet and typing "cabochon.com" on the url bar and seeing nothing come up after that. So just to let you know that we are all anxiously waiting for you to get the game up and running. Also if there is anything you need feel free to ask, because we all understand your situation and we feel that its our responsibility to help you get this game running. This should not be a burden for you to bear on your hands alone, and thus we all should pitch in. Again thanks for making such an amazing game and lets have it running and keep it running.

Thanks,
from me and the 50,000 players waiting anxiously