in reply to <strike>XSL/XML/Perl as a development process</strike>
While I find this interesting, the idea is hardly new: separate the content (usually generated by scripts the programmer writes) from the layout/markup (generated by an "artist" or designer). Much of this today can be achieved with or without XML/XSL by using (X)HTML + CSS with a good backend process for generating content (perl, of course!). Good programmer/designers do this, and good production houses already separate the jobs.
I also feel that a good manager will develop a decent specification that will tell (1) the artist/designer what needs to be on the various pages of a site, including types of content and general layout guidelines, and (2) the programmer what sorts of data need to be consumed and the general output that should be thrown to the layout. If this is done correctly, your "XML as Wall of Separation" argument shouldn't need to be raised at all.
I *do* like your table regarding "Who Do What"; it clearly and cleanly shows that architectural changes to a site affect *everybody* and not just the programmer OR artist. This is too often forgotten.
Re: Re: XSL/XML/Perl as a development process
by chunlou (Curate) on Jun 15, 2003 at 22:37 UTC
|
The problem is not finding new ideas of devel proc but executing any old concept descently.
I rarely have such a "good manager." Examples of spec from the managers could be like:
- "Make it look sexy"
- "Make it flexible"--euphemism for 'I duno what I'm doing'
- "Just turn the paper forms into webpages"--when building an employee performance evaluation application
- "Use a 3D spider web display"--for an org chart--2D info
- "This is exactly what the client wanted!"--no, it wasn't, since we redid the entire project afterwards.
I think I should clarify role-and-responsibility a little bit at this point:
|
Devel Phase |
Role1. |
Req Elicit./Analysis: What to Do |
Design: How to Do |
Coding: Do |
Testing: Done (hopefully) |
Mgr/Client |
lead |
|
|
verify |
Proj Mgr/Sys Analyst |
lead |
lead |
buffer disturbance |
coordinate |
Artist/Programmer |
(as needed) |
lead |
lead |
fix |
QA |
(as needed) |
lead |
|
lead |
Artifacts: |
flowcharts,
screenshots,
use cases...
|
DB schema,
class diagram,
site map,
(prelim) test script2.... |
(you know what...) |
results to the test matrix... |
1.Note that a single person could take multiple roles.
2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.
It is not usually a good idea for an business manager to tell programmers what to do directly. Two reasons:
One, doing so is like a patient (the biz mgr) telling a doc (the programmer) what drug and treatment he (the patient) should take.
Two, if one biz mgr can do it, any of them can. Hence, conflict of interests. Everyone wants their jobs done first. Besides, changes become intractable.
Normally, during Req Elicitation, a Client or Mgr would be like a patient, a Proj Mgr (or Sys Analyst) plays the role of clinical psychologist, literally. It really takes a skillset of a clinical psychologist to do Req Elicitation well. That's why (for me), a good personnel in that role is the most difficult to find.
Unfortunately, Req Elicitation is often the most poorly done. Thus, the tragedy--a bad and wrong biz idea perfectly implemented--which is still a bad and wrong biz idea.
| [reply] [Watch: Dir/Any] |
|
Thought I should round up my answer more even-handedly.
In practice, I feel managers and programmers (or any "technical" personnel) are as much a victim as vilain, since most of them were never taught how to work with each other.
The CS curriculum normally focuses on programming, nothing much on how to work with people. (Like, a programmer might always complain a req spec wasn't "perfect," instead of helping a non-techie how to write a spec.)
A biz program teaches quite a bit of concepts and theories, but not every biz student came out with good implemenation knowledge (theoretical or pragmatic). I usually found them lack of any concept of "stable system" and why you can't meaningful fix and improve a system that's not "stable." Instead, management by crisis or mgt by (annoying) cheerleading is a common style, which often amounts to destablizing a system.
It would be better if mgrs and programmers have overlapping knowledge that helps bridge their communication gap. In an ideal world, we could have the following:
Stylized view of the distribution of knowledge and skill sets
|
knowledge\skill sets
|
|
strategic thinking |
biz sense |
req elicit
(aka mind- reading?) |
req analysis |
design |
programming |
QA (conceptual and/or technical) |
biz/acc't mgr |
|
|
|
|
|
|
|
proj mgr |
|
|
|
|
|
|
|
sys analyst1. |
|
|
|
|
|
|
|
lead programmer1. |
|
|
|
|
|
|
|
programmer |
|
|
|
|
|
|
|
what to do/know: |
if a project/client strategically or technologically compatible & complementing the current sys or products... |
how a project
contributes to
the bottomline,
or to the current system or products... |
ask questions that lead to actionable requirements... |
if each step has adequate input-output params, generalize/ minimize the flowchart... |
generalize, minimize... |
(assume you know best here) |
explain to mgr why the one who programmed shouldn't be the one who tests... |
sample artifacts: |
a sensible executive talks sensibly... |
biz case, justifies proj ... |
flowchart (readable by
clients) w/ indications of input-output params at each step... |
flowchart (meaningful to programmers), conceptual class diagram... |
class diagram, activity diagram, mock screens... |
(assume you know best here) |
test scripts (manual or automated) |
1.sys analyst -- system-wide architectural issues
lead programmer -- individual applications
If people don't come in readily with what it takes, we just have to train them in house (if feasible).
See that, on one hand, the major reasons of the software projects' failure (as a business) are "managerial," rather than "technical;" on the other hand, managerial decision process is a collective effort, not just by titled managers.
| [reply] [Watch: Dir/Any] |
|
|