in reply to Re: Re: XSL/XML/Perl as a development process
in thread <strike>XSL/XML/Perl as a development process</strike>
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
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.
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.
In Section
Meditations