Re: The Value of a CS Degree


bwaichu{at}yahoo.com wrote:
>
> There is no doubt that education is important. What currently bothers
> me about IT people is their inability to complete projects on time or
> with a sense of urgency.

90% of the problem is that management (IT people managing other IT
people, I might point out) fail to set realistic schedules and break
the project down into sufficiently small components. The old saying "If
it weren't for the last minute, nothing would ever get done" comes to
mind here. If you give someone (myself included) six months to do
something, they will screw around for five months and then put in 70
weeks the last month to try and get the task completed.

The solution is quite simple -- a project should be broken down into
sufficient small pieces that realistic milestones can be set two weeks
apart, one month at the very most. This keeps a sense of "urgency"
about the project, which is the greatest motivating factor I've found.

The problem with this approach is that it requires *really* smart
managers who are willing to do the preparatory work creating the
schedule. It means that *they* need to fully understand the project and
have a good grasp of how long each component of the project will take.
The problem there is that few "managers" are so qualified to do this
kind of work.

>
> What I end up finding is IT people talk more than they do.

Again, shorten the milestone period and they start working more. Of
course, what's really happened here is that all the talking has been
pushed onto the managers rather than the programmers. But then, that's
as it should be.

> I also find
> them planning more than they do as well.

Yes, but this isn't necessarily a bad thing.
Case study after case study has shown that poorly planned projects tend
to take *far* more time in the long run than overly-planned projects.
Yes, you can "design a project to death", but this is a management
issue, not a programmer issue.

> What happens, then, is that
> IT people fail to execute well.

Yes, some weaker programmers use "design time" as a way of avoiding the
work that they are most poorly suited for -- the actual coding. If this
is happening in your organization, it's time to get better programmers.

> I don't care how much documentation an
> IT group has if their data is bad or their code fails. This just tells
> me that they suck at both planning and coding. And the absolute worse
> thing is an IT person that is arrogant, while missing deadlines.

One word: insecurity. If someone isn't very good, they will sometimes
use arrogance as a way to hide their inabilities. OTOH, I've seen far
more cases where a *lack* of planning is the real culprit. "Coding
first and designing later" (also known as "hacking") has been the
biggest problem facing this industry.


>
> I hate IT people that tell me how smart they are. If they were so
> smart, they would complete their projects on time.

Being "smart" has nothing to do with it. I cannot tell you how many
projects I've been involved with where an unrealistic schedule was
forced on me. I once wound up losing a job because I *refused* at
accept the schedule that management had come up with. My problem was
that I was a little *too* smart (and arrogance had nothing to do with
it) and I told management that the schedule was unrealistic and would
take about 10 times longer than they were forcasting to do the work.
Their attitude was "well, if you won't do it, someone else will."
Needless to say, the project failed long after I was gone.

It isn't a question so much of being smart or dump as it is of ethics.
Do you go along with a ridiculous schedule just to keep your job? Or do
you tell them the truth and risk losing your job or respect in your
abilities. Let me simply suggest that "standing for for what's right"
on matters like this in the past have tempered my desire to point out
the flaw's in schedules dictated from on high. Today, I point out my
concerns and tell them "well, we'll try it and see what we can do"
without committing myself fully to their schedule.


>
> If CS programs can put more emphasis on doing and on good project
> management,

Here's the problem with CS programs and software engineering: you don't
*ever* work on "real-world" sized projects in a CS program. And until
you've worked on a *large* project (hundreds of thousands or millions
of lines of code), you really can't grasp what the problems are. A
typical 10-15 week course at your local college or university is going
to be pushing it to get students to work on 1,000-5,000 line programs
(which are still trivially small). Students can't even *read* through
an *existing* large program and make sense of it in the time period set
aside for one course. Oh, and don't forget that students are usually
taking three other courses, too.

Perhaps in a masters or PhD program students can gain this kind of
experience. But not as an undergraduate.



> I would welcome them with open arms. I do think assembly
> helps an IT person better explain their code, and it helps me better
> communicate with them since I have to understand how the machine works
> to code it.

I agree 100%
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: systems programming versus application programming
    ... IMO the core reason for that failure rate is that software developers do ... They are too absorbed in the Cult of Creativity to do ... management (e.g., poor estimates, insufficient resources, unrealistic ... them by pushing back on every schedule item. ...
    (comp.object)
  • [Starfall/ACRA/REPOST] Metal Fire #8, False Maria 02
    ... had to deal with a dozen or so of unhappy lazy programmers. ... numbers in formulas and cells to make a schedule that didn't go too far ... jobs, requests for info from systems, and paying prices. ... She was the result of the manipulation ...
    (rec.arts.comics.creative)
  • Re: [OT] Re: Are / Were you a Siebel Software Engineer?
    ... because MIS programmers think in overly syntactic terms and as ... Because Bush's management style happens to resemble that of many MIS ... The gesture common to both worlds is affectless betrayal. ... Dijkstra at first thought "software engineering" to be a good idea as ...
    (comp.programming)
  • Re: The Failure of OOP
    ... >> And many management types and not a few programmers believed ... sealed rooms talking to the vendors, ... documenting object behaviour, ...
    (comp.object)
  • Re: Industry Calls for More Foreign Programmers
    ... in a situation where management alone defines productivity, ... programmers work unpaid, unreported hours. ... as Galbraith shows (most recently in an essay titled The Economics ...
    (comp.programming)