Wednesday, September 23, 2009

Separation of Concerns

If you were at a software company and could only have one person, you'd probably want an engineer, someone to build the product. That person might have an engineer's mindset. Get it working, do what's easiest. They may be less concerned about how the user will use the product (I'm assuming there is an end-user).

The problem with this mindset is the lack of someone to see things from the user's point of view. Engineers typically complain when managers pick a feature set because they can be fickle. Managers become idea generators and can come up with and discard ideas quickly mostly because they don't have to implement the feature.

Meanwhile, engineers have to implement stuff, and so they may not be so motivated to implement something that's easy to use because it may be hard to implement.

However, without a separation of concerns, someone who is relieved of the burden of having to implement a feature, then getting a good product, one users will want to use, is challenging.

Thus, it's very common to have someone be the user advocate. The only problem with this viewpoint is that it's easiest to have the prototypical user be the person making the decisions about what features to implement. In other words, the ideas guy typically doesn't want to talk to lots of people to get their ideas because this person thinks his (or her) ideas are the best, and likes the autocratic nature of making that decision.

So there is the dilemma of trying to create a good product, and thus separating the guy who comes up with the features with the one implementing it, and controlling the idea guy from coming up with ideas that don't make sense and aren't really looking at true users.

No comments: