views:

60

answers:

2

I'm curious how other large-scale development shops (web-focused) divvy up the work between Designers, Developers, and HCI/Consumability Experts.

Obviously:

  • Developers will be writing code
  • Designers will be responsible for graphical assets and probably some HTML/CSS
  • HCI Experts will be doing usability reviews, coming up with usage scenarios, etc.

But what interests me more than these coarse job duties are the relationships and hand-offs between all of these parties that lead to the development and release of a finished product. I know that "process" can be a dirty word for small development houses, but for larger organizations the executives can come to expect that there is at least some sort of agreed-upon process for everything. I'm curious what your process is, or what your ideal process would be.

Previous Discussion

A: 

I've worked for small shops and a very large Fortune 500 company (most of my career) and have seen both extremes of formality in the process. From what I've experienced, the more formal the process, the more it leads to us vs. them situations during the hand-offs. The most successful processes that I've experienced have the gray areas in between where the groups draw the lines among themselves. Some of the keys to successs are good communication between the groups, making sure everyone knows what's expected of them prior things getting under way and making sure you can repeat it if the project was successful.

Whatever the process is, if the project was successful and the process was creative and positive, its probably worth building upon.

Walter
A: 

Division of labour is a nice myth.

The actual English meaning of nice = so naive that you are unobtrusively pleasant. And the meaning of myth = a tale that is so tall and huge but not necessarily untrue but because of its immenseness it's probably not true.

In these days and age of total quality and cost reduction, who in the world would retain personnel for redundant capacity? There are very very few companies no matter how large, would even hire designers purely for the sake of designing web pages.

So their IT would initially have a nice solution which is to get the human resource people, the manufacturing capacity planner, the manufacturing shop floor supervisor, the facilities engineer, the training and testing coordinator, etc, etc, to design their respective web pages.

But no, these people don't care what MVC is all about, much less about code-behind xml. And those production supervisors who suddenly get so excited about web page design fork off on paths of their own discovering all that could be done with embedding vb and xls and silverlight into their web designs ignoring the grand master mvc plan of the IT dept.

You would then discover that the most mvc intelligent non-IT people on the planet happen to be the physicists, process engineers, electrical engineers, various other engineers and a few technicians - and they have the most developed web content. For the rest you end up having a roster of programmers supposedly to translate uncooperative colleagues' design into the mythical mvc (mythical view controller = grand plan but not necessarily unachievable).

Therefore, the mvc is a mythical but yet another useful concept to help IT personnel maintain and sustain a grand plan in manageable ways. That is, mvc helps to separate tasks so that when you return to a project 6 months later to enhance it, you are able to locate which part to modify easily. Frequently, mvc makes maintenance more difficult because you break up related functions into their respective model, view and control functions and 6 months later you find that making a small enhancement actually involve digging out various huge sets of code with implications and dependencies all over the place.

Therefore, since in reality mvc actually only helps programmers maintain a grandiose plan in most cases (except for the few rare cases where designers are distinctly hired), if inlining codes and violating mvc principles here and there makes your application more maintainable and sustainable - by all means do it.

Blessed Geek
The question really has nothing to do with MVC specifically. More with how large projects are designed and developed from Customer Requirements -> User Scenarios -> UI Mockups -> Working Product/Prototype.
JasonWyatt