Are full life-cycle software developers really the norm?

[T. Hoskins]

In her "Coder" vs "Developer" post Elena wrote:
>Every job since then has been problem analysis, system requirements
>definition, design, code, test, document, implement, train users, etc.
>So I've never had a full-time job where I was just a "coder". And
>honestly, if you are only doing coding in the U.S. job market today your
>days are numbered. Too much overseas competition no matter what your
>experience level is. Maybe there's some specialized niche where you can
>pull that off - - I don't know.

I wonder if this is a "universal truth" or simply one person's perspective?


I do know that many employers (including corporations) have been trying to
hire multi-talented software developers for quite some time now. But is this
really what most of them have gotten?

I think the truth is, that most software development jobs in the USA are
staff augmentation/heads-down coding type of positions. Of course, I have
no way of verifying this assertion, but neither does anyone else.

When I visit this website (DevX Discussion Groups), I see a lot of coding
discussions taking place, but little of anything else. Everytime I have
checked the various design newsgroup on this website, I have noticed that
there was very little (if any) traffic in those newsgroups.

Since I started working in the IT industry, the only universal truth that
I have noticed is that every organization is different and so is every programming
position.

[MarkN]

I don't think they are the norm.

<Q>
When I visit this website (DevX Discussion Groups), I see a lot of coding
discussions taking place, but little of anything else. Everytime I have
checked the various design newsgroup on this website, I have noticed that
there was very little (if any) traffic in those newsgroups.
</Q>

I'm with you on this. Most questions are 'how to do things you shouldn't
be doing'.

[Elena]

>When I visit this website (DevX Discussion Groups), I see a lot of coding
>discussions taking place, but little of anything else. Everytime I have
>checked the various design newsgroup on this website, I have noticed that
>there was very little (if any) traffic in those newsgroups.

Well, let me put it this way. Design takes place. It might be any of the
following:

1. Highly structured effort using some specific methodology spelled out
in 3 or 4 large 3-ring binders with many different kinds of forms to be filled
out, specialized diagrams, team meetings with the appropriate business owners,
group reviews and design walk-thrus, cost estimates, signoffs, etc.

2. Some combination of "departmental practices" which involve asking SOMEBODY
what the heck they want, looking at related systems for interfaces and data
sources, evaluating existing infrastructure to see how it can support the
new request, negotiating which features can be included/excluded in the expected
timeframes, some kind of design document which may or may not be read, several
informal meetings, etc. This can all be done by one person with a lot of
running around provided the organization is not huge.

3. The Lone Ranger rides into town and makes all the decisions as to what
features the application will have and how they will be implemented. He
may end up rewriting large portions of his system because he couldn't fight
off the challenges to the design decisions he made.

No matter how you slice it, design does happen. Good design, mediocre design
or crappy design, there are decisions that somehow have to get made. Now,
if your definition of "design" is limited to a specific methodology, then
you might be correct in saying there is no design. If you're suggesting that
lots of companies have full-time designers on staff to make all those decisions
for the developers, I'd have to say I haven't been in any of those companies.
It usually falls on the developer to figure out how this stuff should be
done.

Forums dedicated to design are tough to work with. I mean, if you're designer
type 1, then you expect people to know your process and diagrams and you
really need to communicate with others of that breed. Also, if it's a design
question of any consequence, it takes about 2 pages of text just to bring
someone else up to speed on what it is you're trying to do. And who want
to read thru 2 pages of text for that?

When I read thru various forums and newsgroups, I usually see design issues
lumped in with other topics such as Tools (like Visual Studio or Dreamweaver)
or specific databases (Oracle, etc.) If someone came up to me and said,
"Hey, let's talk design" I'm not sure we'd have much of a conversation because
I don't discuss design in the abstract - - only as applied to a particular
problem that needs to be solved.

One final thought, devx does seem to have a clientele of mostly programmer
types so that might also be driving the discussions in a certain direction.


Elena

[patch]

Elena wrote in message <3d6fdd7a$1@10.1.10.29>...
>
>>When I visit this website (DevX Discussion Groups), I see a lot of coding
>>discussions taking place, but little of anything else. Everytime I have
>>checked the various design newsgroup on this website, I have noticed that
>>there was very little (if any) traffic in those newsgroups.
>
>Well, let me put it this way. Design takes place. It might be any of the
>following:
>
>1. Highly structured effort using some specific methodology spelled out
[...]
>2. Some combination of "departmental practices" which involve asking
SOMEBODY
[...]
>3. The Lone Ranger rides into town and makes all the decisions as to what
[...]
>No matter how you slice it, design does happen. Good design, mediocre
design
[...]>
>Forums dedicated to design are tough to work with. I mean, if you're
designer
[...]
>When I read thru various forums and newsgroups, I usually see design issues
>lumped in with other topics such as Tools (like Visual Studio or
Dreamweaver)
>or specific databases (Oracle, etc.) If someone came up to me and said,
>"Hey, let's talk design" I'm not sure we'd have much of a conversation
because
>I don't discuss design in the abstract - - only as applied to a particular
>problem that needs to be solved.
>
>One final thought, devx does seem to have a clientele of mostly programmer
>types so that might also be driving the discussions in a certain direction.
>
>
>Elena



*Very* well put Elena.. I'd like to add that there's two major forms of
design-processes: one follows nescessity and the other follows style.. nine
out of ten times these meet somewhere in between..

the first one is relatively easy; you want to communicate, you make a
tele-machine, needs something for my voice and something for my ear. should
be able to operate with one hand while roaming my house: enter the
mobile-phone.

the other one ain't that simple: style. style is a concept and as such hard,
if not impossible, to describe. but what you end up with is mostly a mix of
what's hype in the public's eye, whats hype in the client's eye and what's
going on in the designers mind.

now, the first one is easyer to talk about since you can work within problem
v.s. solution frame of mind. hence the large amount of "coding discussions
taking place" the other is something people are payed for (very well) to
discuss about in (often) closed brainstorm-sessions. what, there's companies
nowadays who's sole buisness is to discuss about these things all-day-long.
so no way these are going to shoot-the-breeze online.. that they'll do in
concept-bars and semi-interesting art presentations (been there, done that)
preferably on the boss or clients account..


patch

[Missy]

Elena,

I hear what you are saying however;
(references your numbering below)

1. Sounds like the entire development process, not simply DESIGN

2. These activities are Analysis and Requirements Specification activities...
we SHOULD attempt to separate the WHAT (Analysis and Requirements Phases
of Development) from the HOW .... DESIGN.

3. Lone Rangers.....(aka "Cowboys") should ride horses and stay out of DESIGN....
Frankly it doesnt surprise me to hear that "he may have to rewrite all his
code" as clearly by "making all the decisions regarding features" without
completing at the very least a SPECIFICATIONS document (part of Requirements)
he horse wont have two legs to limp on legally.

DESIGN...... is just that the process of determining HOW the WHAT will be
provided for within the target product.

...and although Design does happen....good, bad and ugly, it undoubtadly
has a better chance of being "GOOD" when the Designer has at least a basic
understanding of the position of DESIGN within the development process.

Small wonder "code and fix" appears to be the coloquial industry standard!




"Elena" <egermano@comcast.net> wrote:
>
>>When I visit this website (DevX Discussion Groups), I see a lot of coding
>>discussions taking place, but little of anything else. Everytime I have
>>checked the various design newsgroup on this website, I have noticed that
>>there was very little (if any) traffic in those newsgroups.
>
>Well, let me put it this way. Design takes place. It might be any of the
>following:
>
>1. Highly structured effort using some specific methodology spelled out
>in 3 or 4 large 3-ring binders with many different kinds of forms to be
filled
>out, specialized diagrams, team meetings with the appropriate business owners,
>group reviews and design walk-thrus, cost estimates, signoffs, etc.
>
>2. Some combination of "departmental practices" which involve asking SOMEBODY
>what the heck they want, looking at related systems for interfaces and data
>sources, evaluating existing infrastructure to see how it can support the
>new request, negotiating which features can be included/excluded in the
expected
>timeframes, some kind of design document which may or may not be read, several
>informal meetings, etc. This can all be done by one person with a lot of
>running around provided the organization is not huge.
>
>3. The Lone Ranger rides into town and makes all the decisions as to what
>features the application will have and how they will be implemented. He
>may end up rewriting large portions of his system because he couldn't fight
>off the challenges to the design decisions he made.
>
>No matter how you slice it, design does happen. Good design, mediocre design
>or crappy design, there are decisions that somehow have to get made. Now,
>if your definition of "design" is limited to a specific methodology, then
>you might be correct in saying there is no design. If you're suggesting
that
>lots of companies have full-time designers on staff to make all those decisions
>for the developers, I'd have to say I haven't been in any of those companies.
> It usually falls on the developer to figure out how this stuff should be
>done.
>
>Forums dedicated to design are tough to work with. I mean, if you're designer
>type 1, then you expect people to know your process and diagrams and you
>really need to communicate with others of that breed. Also, if it's a design
>question of any consequence, it takes about 2 pages of text just to bring
>someone else up to speed on what it is you're trying to do. And who want
>to read thru 2 pages of text for that?
>
>When I read thru various forums and newsgroups, I usually see design issues
>lumped in with other topics such as Tools (like Visual Studio or Dreamweaver)
>or specific databases (Oracle, etc.) If someone came up to me and said,
>"Hey, let's talk design" I'm not sure we'd have much of a conversation
because
>I don't discuss design in the abstract - - only as applied to a particular
>problem that needs to be solved.
>
>One final thought, devx does seem to have a clientele of mostly programmer
>types so that might also be driving the discussions in a certain direction.
>
>
>Elena

[simon]

"Missy" <grouptwelve@hotmail.com> wrote:
>1. Sounds like the entire development process, not simply DESIGN
>
>2. These activities are Analysis and Requirements Specification activities...
> we SHOULD attempt to separate the WHAT (Analysis and Requirements Phases
>of Development) from the HOW .... DESIGN.
>
Both 1 and 2 vary based on the size of the projects and based on (as Elena
said) how structured your organization is. There is no one formula that
fits all.


>3. Lone Rangers.....(aka "Cowboys") should ride horses and stay out of
DESIGN....
>Frankly it doesnt surprise me to hear that "he may have to rewrite all his
>code" as clearly by "making all the decisions regarding features" without
>completing at the very least a SPECIFICATIONS document (part of Requirements)
>he horse wont have two legs to limp on legally.
>
Most companies do not like to hire "Lone Rangers". They believe that a "Team
Player/Builder" is more valuable to the company than a "Superman" (oh, or
"Superwoman"). =)

simon.

[simon]

"patch" <pretpet[no]@[spam]hotmail.com> wrote:
<snip>
>now, the first one is easyer to talk about since you can work within problem
>v.s. solution frame of mind. hence the large amount of "coding discussions
>taking place" the other is something people are payed for (very well) to
>discuss about in (often) closed brainstorm-sessions. what, there's companies
>nowadays who's sole buisness is to discuss about these things all-day-long.
>so no way these are going to shoot-the-breeze online.. that they'll do in
>concept-bars and semi-interesting art presentations (been there, done that)
>preferably on the boss or clients account..
>
Precisely. I have been involved in some private (members only) discussion
groups that talk about abstract topics like design patterns and heuristic
evaluations vs usability testing. As Patch said, these people are not going
to blanket such discussion on unrestricted newsgroups like devx.

simon.