
Joel Spolsky's latest Inc Article: How Hard Could It Be?: The Unproven Path - prakash
http://www.inc.com/magazine/20081101/how-hard-could-it-be-the-unproven-path_Printer_Friendly.html
======
swombat
Summary: Joel Spolsky discovers that people matter more than processes.

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).

~~~
gruseom
_just have a handful of super-productive guys with a loose mandate and good
motivation_

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.

~~~
thorax
Please describe how he "turned out to be...". It will surely help others avoid
it.

~~~
gruseom
He turned out to be abusive and incapable of collaboration. He would say
things like, "From now on, nobody except me makes any creative decision. If
you have a creative idea you need to clear it with me first." I know it's hard
to believe, but that wasn't a joke.

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?)

------
JoelSutherland
_I knew there was no chance that would happen, given that Jeff pulled his
timeline completely out of thin air, but I humored him. In reality, it took
about twice as long as that, which wasn't that bad, but it was still a 100
percent overrun._

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

~~~
anthonyrubin
They have talked about it on the podcast. It is all good-natured ribbing.

~~~
JoelSutherland
Agreed -- but this is a different venue than a podcast they are both on.

------
subbu
When 2-3 bright engineers are working on something they very precisely
(usually) know what they are doing. If one of them says "It's going to take
six to eight weeks" then all the planning would've already happened in the
programmer's brain. Even if it takes twice as much (10-12 weeks or about 3
months) it's not much because the baseline itself is pretty small. With this
mental planning, spending time on bug tracking and filling a spreadsheet is a
waste of his productive time. They will find tools like Twitter far more
useful than FogBugz. In this case Twitter acts as more of communication tool
than a project management tool.

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.

~~~
anthonyrubin
Unfortunately most companies don't put much thought into the tools and
processes they use. They simply do what everyone else is doing. This is why
monstrosities such as Quality Center are popular even though they are
disgustingly expensive and of questionable value.

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.

------
r00k
Nice job linking to the printer-friendly version. Seriously.

~~~
prakash
thank you.

------
geebee
This is the kind of article that makes me wish programmers studied creative
writing or fine art or film making more often. I did a lot of creative writing
in college and beyond, and the spectrum for what works is exceptionally wide.
Some people are paralyzed without an extremely detailed outline and keep
almost everything the write, while other people fill hundreds of pages with no
planning and slowly filter out the words, expecting nothing more than a few
dozen usable pages.

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."

------
gjm11
Prakash, if you're reading this and can amend the title: "Joel Spolsky", not
"Joels SPolsky".

~~~
prakash
oops, sorry, didn't see that, can't edit now.

