Alex Iskold of RWW blogged about what programmers should know. (Alex was a software architect with IBM). Here was my comment:
In the end I think that a laundry list like this isn't very useful: there's too much genuine specialization in programming these days (and quite a lot of fake specialization).
I left out some important roles though. Here they are.
There are other roles, like QA, support, product manager, project manager, team lead, and IT. Of these four product managers are rather an interesting role because a lot of people don't really understand why they are needed. What need do they fill? They are the distillation of "focus". They don't necessarily come up with the product, but whatever the definition turns out to be they work to make sure everyone understands the product, and makes sure that feedback gets to the right ears as development progresses, and after the product is released. They may also be tasked with tracking the performance of the product. If the team is focused (and small), and the performance of the product is obvious enough, a product manager isn't needed. The focus of the product manager is "functional clarity" and should be a great communicator, detail-oriented and understand the domain well.
The project manager serves a similar purpose as the product manager, but instead of answering "what?" they answer "when?", and takes action when things slip. Usually the team gives the PM a schedule they are comfortable with, and inform the PM about their progress as needed (usually at fixed checkpoints). Again if the team doesn't have a problem keeping schedules, a project manager isn't needed. The focus of the project manager is "the schedule" and might use a tool like MS Project. Ideally they've presided over similar projects so that they can spot missing or risky elements in the schedule.
Another role that is sometimes a bit confusing, is the team lead, or development manager. It's a confusing role because, at first glance, it seems like a conflict with the PM roles. This person hires, fires, mentors, grows, gives kudos and criticism, and assigns responsibilities, and chooses architecture. They are an experienced technical person with lots of skill and ability, and good communication skill. If a programmer has a technical problem, or if they make a technical mistake, the lead should help out. The lead also sets the tone for the culture, and has authority to define coding conventions and process. Setting policy, representing the team elsewhere in the company, and conflict resolution are key qualities. If the team has consensus on policy, and is always willing and able to help each other out, and no-one is ever hired or fired, no team lead is needed. Sometimes the technical aspects of this role are seperated into a high level technical role and delegated to a title like an architect.
You will notice that there is no mention of who defines the product in any of these roles. The prod manager clarifies. The proj manager babysits and worries. The team lead gets it done. Who is the product definer? The answer is: the guy with the money. They may choose to delegate that authority, and it often gets redelegated. Typically the investor picks a board who picks a CEO who might in turn delegate product definition to the product manager (for example). Or he may put a more complex policy in place for product definition. But in the end, the investor has some idea as to what they are investing in, and will generally be happy if they get what they paid for. (Of course they might also be happy if they get something they didn't pay for but which turns out to be wildly successful.)
Everyone wants to define the product. QA does, support does, even the sysadmin has a few ideas and pet peeves. The users sure as heck do. The product manager role exists to protect the development team (and everyone else) from constantly changing priorities, features, and demands. The risk for the prod man is that the CEO (or the board) will set a product definition policy and then repeatedly break it, undermining the prod man's authority and effectively making their role worthless. It often happens that product managers devolve into fall guys for inefficient and indecisive management. Basically, the people with the money have to have discipline.
Who should define the product? That's the million dollar question! At least in the software business, it's should be the person with the best grasp of the market (what's needed) and of the technology (what's possible). If you add to that the ability to get it done, and some money, you have a business. The definer has to understand the users and filter through their feedback. They have to understand what can be done. They have to understand the psychology of consumerism, and the entire gestalt of the product and it's position in the market, and in the mind of the user. And they have to be able to delegate! A completely specified product is the product itself, so it's impossible for a person to define everything for a complex product. In particular, the development team will need to make lots of little decisions, and possibly a few big ones, as they flesh the product out. (I commonly see two points of failure here: dev is not given authority to define product details, or dev is not being willing to define product details.)
How are products defined? If products were cheap enough, and the market large enough, we could create every possible product, release them all and go with the one that 'sticks'. We can make the product cheaper, and subsitute an expert opinion for the market, and approximate this approach using mockups and prototypes. So, the money champions an idea, requests a prototype, they give and get feedback on it, iterate, then finalize it with the product manager and authorize development. The users then get the "final" product and a similar, if slower, iteration occurs.
(This means there's a highly desirable pressure to minimize the distance between a mockup and production code - a great opportunity for architectural innovation!)
Know a craftsman by his tools. A programmer (text editor) cannot create a whole system - he requires at least a graphic designer (Photoshop), a business person (Phone), and an admin (bash & vi). They make it pretty, sell it, and keep it running respectively.
Furthermore, there is a useful distinction between front-end and backend programmers. The front end guy must know HTML CSS JavaScript regex XML JSON HTTP TCP/IP plus a handful of JavaScript libraries, coding conventions, browser quirks, and a few specific JavaScript libraries, and some human interface guidlines. A good design sense doesn't hurt, either. He'll be using a text editor + firebug + http proxy + a small set of command line tools like curl. (This could also be a Flash or GWT specialist).
The back-end guy must know Java (or Perl or Ruby or whatever) plus a variety of core libraries (like Collections, JDBC) and a variety of application frameworks (SpringMVC, Rails, etc), and of course be a SQL expert. He knows about REST, caching, and scaling. The more he knows about the OS (process overhead, security, etc) and network architecture, the better. This is the guy you seem to be describing in this article. He'll be using Eclipse and a database client, like SQLyog, and the build system.
The admin's primary goal is to keep the application running, but he has a lot of programmer-like qualities, mainly for doing ad hoc scripts. He should know everything about the db, the os, and the network. He lives in SSH, the command line and in configuration files. This is the cloud computing specialist (although certainly the backend programmer should know something about it, too).
In the end I think that a laundry list like this isn't very useful: there's too much genuine specialization in programming these days (and quite a lot of fake specialization).
I left out some important roles though. Here they are.
There are other roles, like QA, support, product manager, project manager, team lead, and IT. Of these four product managers are rather an interesting role because a lot of people don't really understand why they are needed. What need do they fill? They are the distillation of "focus". They don't necessarily come up with the product, but whatever the definition turns out to be they work to make sure everyone understands the product, and makes sure that feedback gets to the right ears as development progresses, and after the product is released. They may also be tasked with tracking the performance of the product. If the team is focused (and small), and the performance of the product is obvious enough, a product manager isn't needed. The focus of the product manager is "functional clarity" and should be a great communicator, detail-oriented and understand the domain well.
The project manager serves a similar purpose as the product manager, but instead of answering "what?" they answer "when?", and takes action when things slip. Usually the team gives the PM a schedule they are comfortable with, and inform the PM about their progress as needed (usually at fixed checkpoints). Again if the team doesn't have a problem keeping schedules, a project manager isn't needed. The focus of the project manager is "the schedule" and might use a tool like MS Project. Ideally they've presided over similar projects so that they can spot missing or risky elements in the schedule.
Another role that is sometimes a bit confusing, is the team lead, or development manager. It's a confusing role because, at first glance, it seems like a conflict with the PM roles. This person hires, fires, mentors, grows, gives kudos and criticism, and assigns responsibilities, and chooses architecture. They are an experienced technical person with lots of skill and ability, and good communication skill. If a programmer has a technical problem, or if they make a technical mistake, the lead should help out. The lead also sets the tone for the culture, and has authority to define coding conventions and process. Setting policy, representing the team elsewhere in the company, and conflict resolution are key qualities. If the team has consensus on policy, and is always willing and able to help each other out, and no-one is ever hired or fired, no team lead is needed. Sometimes the technical aspects of this role are seperated into a high level technical role and delegated to a title like an architect.
You will notice that there is no mention of who defines the product in any of these roles. The prod manager clarifies. The proj manager babysits and worries. The team lead gets it done. Who is the product definer? The answer is: the guy with the money. They may choose to delegate that authority, and it often gets redelegated. Typically the investor picks a board who picks a CEO who might in turn delegate product definition to the product manager (for example). Or he may put a more complex policy in place for product definition. But in the end, the investor has some idea as to what they are investing in, and will generally be happy if they get what they paid for. (Of course they might also be happy if they get something they didn't pay for but which turns out to be wildly successful.)
Everyone wants to define the product. QA does, support does, even the sysadmin has a few ideas and pet peeves. The users sure as heck do. The product manager role exists to protect the development team (and everyone else) from constantly changing priorities, features, and demands. The risk for the prod man is that the CEO (or the board) will set a product definition policy and then repeatedly break it, undermining the prod man's authority and effectively making their role worthless. It often happens that product managers devolve into fall guys for inefficient and indecisive management. Basically, the people with the money have to have discipline.
Who should define the product? That's the million dollar question! At least in the software business, it's should be the person with the best grasp of the market (what's needed) and of the technology (what's possible). If you add to that the ability to get it done, and some money, you have a business. The definer has to understand the users and filter through their feedback. They have to understand what can be done. They have to understand the psychology of consumerism, and the entire gestalt of the product and it's position in the market, and in the mind of the user. And they have to be able to delegate! A completely specified product is the product itself, so it's impossible for a person to define everything for a complex product. In particular, the development team will need to make lots of little decisions, and possibly a few big ones, as they flesh the product out. (I commonly see two points of failure here: dev is not given authority to define product details, or dev is not being willing to define product details.)
How are products defined? If products were cheap enough, and the market large enough, we could create every possible product, release them all and go with the one that 'sticks'. We can make the product cheaper, and subsitute an expert opinion for the market, and approximate this approach using mockups and prototypes. So, the money champions an idea, requests a prototype, they give and get feedback on it, iterate, then finalize it with the product manager and authorize development. The users then get the "final" product and a similar, if slower, iteration occurs.
(This means there's a highly desirable pressure to minimize the distance between a mockup and production code - a great opportunity for architectural innovation!)
No comments:
Post a Comment