I use fogbugz for my start-up's bug-tracking, and that's something I've "felt" through the application - Joel Spolsky (and, by extension, Fogbugz) believes in what I'd call the "analytical" approach to software development. I know that works for certain kinds of projects - I come from a big consulting background, and I've seen large projects being successfully delivered with those methodologies.

However, I think a not-so-new approach that also works, albeit with smaller teams, is the "just have a handful of super-productive guys with a loose mandate and good motivation" approach. This can be called "agile", but it's not quite that. Agile is not a lack of process - on the contrary, Agile can in fact be more process-heavy than traditional methodologies! This "put great people first" approach is what I'm using on my current start-up, and I believe it works great. You don't know where you're gonna end up or when, but you know that it'll be a great place and that it would have been impossible to plan your way there.

I wonder if larger corporations will ever adopt this model of development (which, imho, is far more effective, though so much less controlled).

I once joined a startup that fit this description. The team included the best programmers I knew in the city, and the CEO was (is) the best person at picking talent I've ever known. I believed, and still do believe, that people are the most important thing, so I wasn't too worried about whether the initial idea would work out. A good team would simply adapt, and this was going to be the best team I'd ever been on.

It didn't work out that way at all because the leader turned out to be... well, if I described how he was, you might not believe me. So let's just say I learned a lesson: the ability to find good people and the ability to lead them are two completely different things, and you can have one without the other. This team never had a chance to get off the ground.

This doesn't contradict what you're saying, but for me it's an important thing to add to the "put great people first" approach.

I'm trying to remember some representative anecdotes for you... for example, our receptionist made the mistake of sending out an investor email without bcc'ing, so the email addresses were all visible. He made her handwrite a note that said, "I apologize for violating your privacy. [The CEO] has instructed me on how to properly send email. I will not do it again" - and write it out 90 times - and mail them to each investor. (You may ask why there were 90 investors... another story.) She told me tearfully that she got RSI from writing out the notes.

Anyway, imagine a whole bunch of examples like that and you'll get the picture.

It was fascinating to observe how the different team members reacted to this person. Most retreated into a shell and didn't speak up as he abused others. There were a few scapegoats who accepted prolonged terrible treatment. There were also a few who acted courageously. For example, when the CEO yelled at one designer for leaving work on a Sunday and told him he would have to apologize to everyone for "letting down the team", the designer said, "In that case, I won't be back" and left. But these latter were a small minority.

It will surely help others avoid it.

Maybe. Sometimes one has to experience things for oneself. The key thing I would say about all this is: if someone is abusive, it doesn't matter whether he's abusing you. What matters is what it tells you about his character. Don't make excuses for people like that. Just avoid them. (Counterargument - Steve Jobs?)

If you're working on your own thing, or you have a client that trusts you, it can blow away other development methodologies. I hear about TDD and BDD, agile this, etc. all the time, but I bet most coders who build something on their own don't actually start with tests etc. I just think that those who do are very vocal about it.

One big issue though is usually documentation. Once you're done, you get the huge sense of accomplishment and it can be a drag to go back and add massive amounts of documentation to what you've just done (not comments, I mean a developer guide for the next guy).

I made a point of not calling it agile either, because agile is actually very structured, not at all chaotic like this mode of development.

An important distinction with cowboy development is that you can do cowboy development with pretty much any programmers, but most programmers are not capable of this mode of development. It requires a very open and sharp mind (ability to discover and absorb new technologies at a very rapid pace and to embrace evolving requirements without always bitching about how requirements aren't stable).

I struggle to find a name for it, though.

Regardless I don't personally associate negative connotations with this method. I'm sure in some situations it can be disastrous, but nothings perfect and I guarantee there have been plenty of agile disasters as well.

The ECD process methodology.

Chapter 1: Core Principles.

- Just build it.

Chapter 2: Defect management.

- Just fix it.

Etc :)

I helping to do it right now for BigCorp X.

So far this year I've helped kick off about 10-12 teams. With another 4 coaches, we've got dozens in-flight. Another 800 or so teams remaining to be trained.

Agile is one of those things that sound easy and a lot like common sense but it can be tricky! And it can be a back-breaker. Try running one-week iterations for a while. Personally, I love it, but one thing is for certain: it sure ain't dull.

I find that to be true. I work at a company[1] that is transitioning to the agile model and we find ourselves working more for the process rather than the process working for us.

[1] Unfortunately I do not work at a startup nor have I started my own. Soon enough though, soon enough.

Spolsky repeatedly throws Atwood under the bus...it seemed condescending and weird to me.

In such small teams 'What are you working on' is more important than filling fields like 'bug type' and 'browser' or 'steps to reproduce'.

As we discover new ways to communicate traditional tools like bug tracking may become obsolete.

This is the failing of the idea that you can take someone who is really good at management (or in most cases, really mediocre) and put them in charge of software developers. When your manager doesn't have a deep understanding of what you do they have little ability to judge how well you do it. So they look at all sorts of questionable metrics, reports and graphs to try to make sense of things.

Software is usually more collaborative than writing, so it's not quite the same thing... but in the end, maybe we shouldn't be surprised when talented people end up producing great things with almost contradictory approaches, and when talented people using similar approaches often produce great results and total catastrophes.

Programming is still mainly art, after all. The only thing that really matters is that you actually do it, and you finish it. There was the advice I read: "you have to write, you have to finish what you write, and you have to publish what you write."