

Lessons Learned for Getting Better Results from Developers - shedd
http://johnnyholland.org/2009/12/30/12-lessons-learned-for-getting-better-results-from-developers/

======
rauljara
This is an excellent list, and I would love to work with someone who ascribes
to it. I also find it a very depressing list, because almost all of those
items involve an awful lot of effort. It's really hard to imagine many people
even half-way living up to it. It ends up making me think of the times I've
done projects for people who have done just about everything the author is
cautioning against.

~~~
hga
Indeed this is an issue, perhaps of the "90% of everything is crud" type. But
it does suggest what you should look for and try to create, groups and
organizations where enough of the people are putting in the effort. We don't
expect them to be common---after all success isn't as common as we'd like---
but it is something to aspire to.

~~~
jimbokun
"90% of everything is crud"

My first interpretation of this was that most development projects are basic
create-read-update-delete applications, but maybe that's not far off from the
intended meaning.

------
mberning
I manage a team of 6 software engineers, and while I like most of this list, I
think #3 will only work for a small team and small-medium projects.

If I took most of the burden on to myself to do the work my engineers don't
like I would be a major bottleneck.

Alternatively, what I like to do, is couch and encourage my engineers through
these less savory tasks so they can get to the development as quickly as
possible.

Edit: You could also argue that it might be worthwhile hiring a business
analyst, but I haven't had much good experience with BAs.

~~~
hello_moto
I don't quite understand what BA does, but where I live, companies are looking
for BA like crazy... so I assume BA is quite useful in a bigger organization
(possibly in a medium to large org).

~~~
mberning
The definition of a BA will vary by organization. I think ideally a BA would
be a person that is familiar with the business as well as the software being
developed. They are the people that can understand and extract all of the
wants of the business and fit them in to a new or existing piece of software
by writing detailed specifications and documentation.

My experience has been that BAs are often unfamiliar with both the business
and the software, which is far from ideal.

------
alxp
"designers speak human and developers speak computer."

I hate this generalization because it can be used as a blanket dismissal of a
developer's opinion.

~~~
jimbokun
Another interpretation is that when a developer speaks "human" he is engaging
in design and when a designer speaks computer he is engaging in development.

------
pxlpshr
Pretty good list but I think the author contradicts the notion and importance
of iteration. No design doc and no code base is free from changes and
improvements, particularly in startups. If you can't deal with changes, you
probably should go work for an enterprise company where you spend half your
time blowing hot air across the table. You can't just write once and leave it
be, the problem with design mockups and wireframes is that they don't really
encapsulate the element of interactivity, and certainly lack customer
feedback.

I also think designers and developers are very much alike even though we often
bang heads. It's a creative process to write code, and I think a lot of people
outside the circle don't appreciate how mentally draining "creation" really
is.

------
edw519
When I read this title, the first thing I thought was, "Oh no, another poser
telling the rest of us what to do based on what they _think_ ".

Boy was I wrong about that. This is an excellent post that could have only
been written by someone who has suffered in the trenches and knows what he's
talking about.

Many of his points:

    
    
      2. Get in bed with the business people 
      3. Ease their pain
      5. No one gives a rip what the artist thinks
      6. You get to control those lovely details
      7. Write it down, write it down, write it down
      8. Get in bed with the QA team
      9. You have to have a middle man
      10. Proximity breeds understanding
      11. Learn to articulate well
    

emphasize that the people part of the process is just as important as the
technical part. This is easy to overlook and we need to be reminded every once
in a while. The main reason we do what we do is not because it's cool (it is),
we do it for and with other people.

The only point I challenge is "4. Force business to iterate in design, not in
development." This is perplexing because it runs counter to most of his other
points. The reason people tend to iterate in development instead of design is
because it's much easier. They're not sure what they want, but once they see
something, they know what they like and don't like about it. I'd alter #4 to
something like, "Learn to prototype well, so everyone is equally comfortable
iterating toward the most desirable outcome."

~~~
jimbokun
"The reason people tend to iterate in development instead of design is because
it's much easier. They're not sure what they want, but once they see
something, they know what they like and don't like about it."

This just happened to my team last week. The designer had pretty comprehensive
mock ups of the site, the stake holders all said "sure, looks good," we
implemented it, and then the stake holders saw it and asked for something very
different from the initial design.

I agree that, to some extent, this is inevitable. However, if you can somehow
teach or convince or trick the business people to give feedback during the
design phase, it would save time overall because modifying mockups take much
less time than actually building something multiple times. That does not
change the need for developers to iterate as rapidly as possible, of course.

------
hga
Very good, the first item is "Be a developer", the author gets it.

------
jimbokun
"If you need an artistic outlet, do it at home, or you’ll always be bitter."

This is equally true for developers.

