Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: XSL/XML/Perl as a development process

by weierophinney (Pilgrim)
on Jun 15, 2003 at 19:50 UTC ( [id://266068]=note: print w/replies, xml ) Need Help??


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.

Replies are listed 'Best First'.
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.
      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://266068]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (4)
As of 2024-03-19 05:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found