RE: Two persons per product

<moved from the M-L tech list>

There's always been a similar debate about management, ie who makes a better
manager of a technical department like IT?  An MBA who has specialized in
the management process, or someone who is technically proficient and who can
communicate with technical folks.

There are pros and cons to both sides but, in my experience, the far better
manager is one who has specialized in being a generalist.

You definitely sacrifice something by not specializing in either the
management or the technical side.  But IMHO there's a lot to be gained by
knowing just enough about both.  You eliminate an entire layer of management
that way.  The benefit SURE isn't less payroll costs...  It's eliminating
the "friction", ie the wasted heat, that always results because something is
lost in the translation between 2 people.


I believe this, about management, because I've seen it in the strange
permutations I've seen happen between an end-user's request and the code
that was finally delivered to solve that user's initial problem.


JMHO.

jt
(back on the accounting trail, probably for the rest of the morning)=:

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of jt
| Sent: Wednesday, December 12, 2001 8:33 AM
| To: midrange-l@midrange.com
| Subject: RE: Two persons per product"
|
|
| Guys,
|
| I'm gonna attempt, again, to move this to the Non-Tech list.  (That's
| probably the easiest way to kill a thread...;-)  I'll cross-post this over
| there, with some additional comments.
|
|
| Where is this discussion leading...?  Who knows...?!?
|
|
| ===> But there is one subtle point of agreement throughout all
| these posts:
| that one individual can BOTH design and code an app.  That's been
| the common
| theme, in the discussion of whether "two eyes are better than one" or not.
|
|
| This is NOT a given, however.  In fact, I'd say it's the exception to the
| general rule in the industry:  you need one personality-type to specialize
| in designing an app, and a second personality-type to code the thing.
|
| IMHO, there are both advantages and disadvantages to EVERYTHING,
| and this is
| no exception.  It's a two-person team approach, also, but not the one I've
| found works best.  Not to say that the Analyst vs. Programmer concept
| doesn't work, and not to say that it's never appropriate to use.  I just
| haven't found, in my experience, the kind of projects where this approach
| actually works better than a two-person P/A team.
|
|
| jt
|
| | -----Original Message-----
| | From: midrange-l-admin@midrange.com
| | [mailto:midrange-l-admin@midrange.com]On Behalf Of Leif Svalgaard
| | Sent: Wednesday, December 12, 2001 1:05 AM
| | To: midrange-l@midrange.com
| | Subject: Re: Two persons per product"
| |
| |
| | From: Brad Jensen <brad@elstore.com>
| | > > The design is what comes before the source code. Some people
| | > > don't have any design, they start writing code right away.
| | > > The execution of the design is writing the source code,
| | > > that is: transforming the design ideas into executable reality.
| | >
| | > If you are a good programmer the design and the coding are
| | > interactive and synergistic. Any design that survives the coding
| | > unscathed is a trivial design, it is really just ordering form a
| | > menu.
| |
| | This may be true for small programs, but is false for large
| | projects (with, say, 500 programs). The discussion does
| | not lead anywhere because most people are too emotional
| | about it. Many smaller shops work in a way that does not
| | scale up (and most shops are happy about this, some even
| | proud of it).
|
| _______________________________________________

<moved from:>

| This is the Midrange Systems Technical Discussion (MIDRANGE-L)
| mailing list
| To post a message email: MIDRANGE-L@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| Before posting, please take a moment to review the archives
| at http://archive.midrange.com/midrange-l.
|