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."
"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.
A cited subset "emphasize that the people part of the process is just as important as the technical part", and I'd argue "1. Be a Developer" does as well.
In that case, while in and of itself it's technical, it's the minimum required to work well with developers and is a prerequisite for doing part "10. Proximity breeds understanding" well. It also lets you effectively "3. Ease their pain", since you understand it at some level.
A lot of it comes down to respect and what falls out of that. It's clear the author respects everyone in the process and that goes a long way towards making the disparate functions and people cohere.
I think I'd like to work for this guy: he'd let me hunker down on "engine" work as I prefer most of the time, would welcome the times I want to do HTML/AJAX GUI work, and be very happy about my focus on the big picture, requirements, hand off to QA and production, etc. etc. etc.
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.
The problem is that there are actually two problems:
- Knowing and internalizing the perspective embodied in this post.
- Remembering to actually apply it mid-project where everything is messy and you are stressed and and and and and...
I try very hard to do the right thing, but I know that I'm not perfect and sometimes I fall back into the wrong way of working/communicating. Thankfully someone usually points that out so I can fix it before it's too late :-)
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.
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.
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.
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).
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.
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.
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.
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:
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."