The Artima Developer Community
Sponsored Link

C++ Community News Forum
More Trouble with Programming

54 replies on 4 pages. Most recent reply: Dec 21, 2006 5:49 AM by Paul M. Dubuc

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]
Walter Bright

Posts: 13
Nickname: walterb
Registered: Jul, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 10:06 AM
Reply to this message Reply
Advertisement
> The trouble is that *many* - especially in the
> non-programming levels of management - dream of miracle
> cures, such as "just have business people outline the
> business rule and then generate the code from those" or
> "use UML; never code" or "exclusively use a really simple
> and really safe language and you don't need to hire
> university graduates" (by "really simple" people sometimes
> mean "simpler than the original Java"). This is seriously
> unrealistic, but not a complete carricature. It affects
> people's attitudes to education, training, and reward
> structures. It of course also affects people when they
> consider what's important in realistically complex
> programming languages and especially when they consider
> what features and techniques that it is worth while to
> learn and use.

I agree with you there. Too many times people are seduced into thinking the latest programming fad is a magic bullet. But there is steady improvement - after all, the vast increase in what programs do is a direct result of programming tools getting better.

Walter Bright

Posts: 13
Nickname: walterb
Registered: Jul, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 10:38 AM
Reply to this message Reply
> The solution to the air traffic safety problem wasn't just
> better plane design. It was a whole complex mass of
> approaches including better planes, better airports,
> better airspace control, better pilot training, better
> differentiation of different role in the air traffic
> system, better controls for the pilots to use, better
> tools for the air-traffic controllers to use, better
> systems for gathering and presenting weather data, and
> much, much more. The results have been quite spectacular -
> and took many decades to mature.

I agree with all your points but one - pilot training isn't better. The previous generation of airline pilots were arguably much more skilled, as they learned their craft pushing airplanes to the limit in combat. Current pilots simply do not get such training.

What has happened is the tools (all the other things you mentioned) got better to more than compensate.

> And part of the solution was licensing. You just don't fly
> a 747 without serious general education, serious specific
> training, and a license.

If you removed all government licensing requirements tomorrow, nothing would change. Do you think an airliner would let the likes of you or me even sit in the pilot's seat of a 747? They've got billions of dollars in cost and liability flying on each 747. No matter how easy it is to fly, they're not going to risk anyone but their best pilots in the seat.

> Raising our sights from plummers and accountaints to
> pilots and surgeons, we realize that other professions are
> respected as professions partly because they have a
> generally accepted shared body of knowledge required by
> practitioners.

I strongly disagree with this. We don't respect them because they have a government license. There are accreditations we do respect, such as a Harvard law degree. Although government licenses are often sold as a way to raise the level of expertise in a field, the real reasons are more along the lines of restricting the supply of practitioners so the fees can be raised.

> In theory, I'm strongly in favor of differentiation of the
> roles in software development, with licensing. However, I
> just can't see who should define the "shared body of
> knowledge" required for licensing tests. We would risk the
> some of the worst practices becoming mandated.

Even worse than that, in this country, professional licensing has been used not to drive quacks out, but to drive out minorities and women. Furthermore, even if that shared body of knowledge is perfectly defined, in a fast moving field like software, government regulation is hardly likely to keep up.

> However, I
> do consider "a required shared body of knowledge" as the
> ideal - for now, we may have to settle for an attempt to
> improve education and training, hopefully guided by
> relevant research.

I think it's a fine idea for universities to define such for their degree programs. It's a kind of accreditation that works. Just keep the law out of it.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming Posted: Dec 9, 2006 10:55 AM
Reply to this message Reply
> I think it's a fine idea for universities to define such
> for their degree programs. It's a kind of accreditation
> that works. Just keep the law out of it.

So it's government involvement you are against, rather than the idea of licensing as such?

The trouble with universities is that there are so many of them and that the quality and contents of degree vary enormously even among acredited institutions. There is no minimal standard for software developers; not even a generally accepted definition of "software developer" (or any related term).

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Walter Bright

Posts: 13
Nickname: walterb
Registered: Jul, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 11:19 AM
Reply to this message Reply
> So it's government involvement you are against, rather
> than the idea of licensing as such?

Yes.

> The trouble with universities is that there are so many of
> them and that the quality and contents of degree vary
> enormously even among acredited institutions. There is no
> minimal standard for software developers; not even a
> generally accepted definition of "software developer" (or
> any related term).

I regard that as a strength, not a weakness. There is no one size fits all solution, and people who want to use software engineers can pick the accreditation that fits their needs the best. All that variation means that universities are able to rapidly adapt to changing times.

Look at the dynamism going on in software development. I don't think it's a coincidence that slow moving fields are saddled with government regulation, and fast moving ones aren't.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming Posted: Dec 9, 2006 12:14 PM
Reply to this message Reply
> The trouble with universities is that there are so many of
> them and that the quality and contents of degree vary
> enormously even among acredited institutions. There is no
> minimal standard for software developers; not even a
> generally accepted definition of "software developer" (or
> any related term).
>

From what I've seen, computer science programs on different universities seem to differ in the amount of information given to students and required by schools but they are all similar in the way they teach. However, not all people learn best in the same way; for example, some people are good at absorbing material from a text book, while others learn best through practical work, and yet others might learn best through a combination of these.
Do you think schools should offer a variety of degrees or programs to accomodate for these different learning methods?

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 12:14 PM
Reply to this message Reply
> > So it's government involvement you are against, rather
> > than the idea of licensing as such?
>
> Yes.

Again, the fundamental problem is that high-quality work is rarely demanded from developers in the first place. If it was, they would have delivered it.

IMHO, licensing would simply bring up the price of the software, without any effect in the quality.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming Posted: Dec 9, 2006 12:54 PM
Reply to this message Reply
>> Again, the fundamental problem is that high-quality work
> is rarely demanded from developers in the first place. If
> it was, they would have delivered it.

I fear that you are an optimist:
(1) Often it is not just that "high-quality work is rarely demanded" but that rules are in place that ensure that code is badly structured.
(2) like many managers, many programmers couldn't recognize well structured code if they saw it, let alone produce it;
"the system" has adapted itself to this "sloppiness".

This "sloppiness" feeds on itself: developers are not rewarded for knowing non-trivial development techniques, so they don't learn them, so those techniques aren't used, so those techniques aren't taught, so the developers don't know them, so the techniques don't work in real life.

The constant search for "the next big thing" and "the silver bullet" is actually a symptom.

No, I don't think things are that bad everywhere; I just wanted to emphasize the seriousness of the problem.

I often wonder what this "ordinary programmer" that people keep referring to is like. The professional/educational backgrounds, skills, and talents of people who develop software differs by orders of magnitude in just about any dimension you care to measure. Maybe I'm just too close to the software world, but my impression is that in other fields the variability within a job classification is significantly less than for "programmer" or "software developer".

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Walter Bright

Posts: 13
Nickname: walterb
Registered: Jul, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 1:08 PM
Reply to this message Reply
> The professional/educational
> backgrounds, skills, and talents of people who develop
> software differs by orders of magnitude in just about any
> dimension you care to measure. Maybe I'm just too close to
> the software world, but my impression is that in other
> fields the variability within a job classification is
> significantly less than for "programmer" or "software
> developer".

I've worked in other professional fields - such as mechanical engineering. The variation is just as wide. I once hired a CPA who turned out to know less about accounting than I did.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming Posted: Dec 9, 2006 1:34 PM
Reply to this message Reply
> This "sloppiness" feeds on itself: developers are not
> rewarded for knowing non-trivial development techniques,
> so they don't learn them, so those techniques aren't used,
> so those techniques aren't taught, so the developers don't
> know them, so the techniques don't work in real life.

I often run into the 'we aren't software company' when I try to do something in a non-naive way or write a customized toolkit for reoccurring problems in an IT department. Never mind that the people who 'do write software' have unusable or ineffective solutions if they have one at all.

> I often wonder what this "ordinary programmer" that people
> keep referring to is like. The professional/educational
> backgrounds, skills, and talents of people who develop
> software differs by orders of magnitude in just about any
> dimension you care to measure. Maybe I'm just too close to
> the software world, but my impression is that in other
> fields the variability within a job classification is
> significantly less than for "programmer" or "software
> developer".

The real problem is that most of these titles don't mean anything in software/IT and if they do, they mean completely different things in different organizations. I moved from being a 'Systems Analyst' at one job to being a 'Systems Analyst' at another and it was a huge promotion.\

I think the biggest problem in software and IT these days is that the mentor system has been broken. Companies want only the very experienced designers on site and all the 'developers' off-site (often off-shore) or as contractors. The problem with this is that the architect-builder relationship isn't sensible in software. An architect creates a blueprint that tells the contractor exactly what to do. In software we try to have an 'architect' give the developers a design but these designs are really more like concepts. Kind of like if an architect gave a builder a sketch of the outside of a building and some basic requirements like '3 bedrooms'. They don't tell the developer exactly how to build the system. If they did, it's essentially equivalent to a compilable software program and if that's the case, why write it once and then write it again?

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 2:20 PM
Reply to this message Reply
> I fear that you are an optimist:
> (1) Often it is not just that "high-quality work is
> k is rarely demanded" but that rules are in place that
> ensure that code is badly structured.
> (2) like many managers, many programmers couldn't
> dn't recognize well structured code if they saw it, let
> alone produce it;
> "the system" has adapted itself to this "sloppiness".
>
> This "sloppiness" feeds on itself: developers are not
> rewarded for knowing non-trivial development techniques,
> so they don't learn them, so those techniques aren't used,
> so those techniques aren't taught, so the developers don't
> know them, so the techniques don't work in real life.

And that's exactly what I mean: if the high quality is demanded, the developers will quickly (OK, "quickly" is maybe too optimistic) learn what a well structured code is and how to write it. I even worked in a place where this was the case - God knows how I miss these days :)

The only way to break the vicious cycle you mention is to actually demand the quality - in most places where software is developed it is not the case; worse, they think that striving for the quality means lesser productivity.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming Posted: Dec 9, 2006 3:05 PM
Reply to this message Reply
> I often run into the 'we aren't software company' when I
> try to do something in a non-naive way or write a
> customized toolkit for reoccurring problems in an IT
> department.

To be honest, I still don't understand why non-software companies are developing software in the first place.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming Posted: Dec 9, 2006 3:38 PM
Reply to this message Reply
> To be honest, I still don't understand why non-software
> companies are developing software in the first place.

Probably to use it for their internal needs.

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: More Trouble with Programming Posted: Dec 9, 2006 9:30 PM
Reply to this message Reply
I may be naive but in my world, I'm annoyed by unecessary complexity that comes with execution. I always get problems with feedback. If I call a function, I can't call another one until it returns, except for nested functions. This is a first in, last out execution model otherwise known as a stack. Nothing is abstracted away. I have tons of tools for data structures, but none to handle different types of execution. And the feedback problem I have is if a nested call need to update a calling object higher up. It's not supposed to know what these objects are or even that it may risk an infinite recursion. So I end up using queues or round-robin updates. It works great, but I'm working around OO.

So not only do I have to keep track of data, I have to make sure my execution stack doesn't get messed up. It gets worse. Because of this top down execution chain, certain functions (or methods) have higher priority than others. Some of them want to (MUST) control what objects get a turn and when. This has the effect that applications are built differently than libraries. This is asinine. Applications should be usable just like libraries. It was common practice in the '80s on the Amiga at least to provide an external application interface for each app that you wrote (so that other apps could use your app's functionality). But much of it had to be manually built (external GUI access was free). The only reason that apps can't naturally be treated as libraries is because of the execution model. Libraries are written assuming others will call them. Applications are built assuming they will call other functions, but never BE called itself. So when you try to use two apps together, it's almost impossible. Who gets control? And how do you reorder the calls? Like I said, all this is low level and a bitch.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming Posted: Dec 10, 2006 6:28 AM
Reply to this message Reply
> > I often run into the 'we aren't software company' when
> I
> > try to do something in a non-naive way or write a
> > customized toolkit for reoccurring problems in an IT
> > department.
>
> To be honest, I still don't understand why non-software
> companies are developing software in the first place.

Partly because vendors and contractors usually fail to execute with the required level of quality and because it's often cheaper to employ some developers that know your business and needs than to pay through the nose to have some contractors come in and make a mess of things and then leave. It's not software packages that are being written (I've done that too) it's components that act as glue between different packages or fill in gaps in those packages.

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: More Trouble with Programming Posted: Dec 10, 2006 11:08 AM
Reply to this message Reply
> if the high quality is
> demanded, the developers will quickly (OK, "quickly" is
> maybe too optimistic) learn what a well structured code is
> and how to write it. I even worked in a place where this
> was the case - God knows how I miss these days :)
> The only way to break the vicious cycle you mention is to
> actually demand the quality - in most places where
> software is developed it is not the case; worse, they
> think that striving for the quality means lesser
> productivity.

It's interesting to see a discussion about C++ drift off to complaints about programmer "sloppiness". The question rather ought to be: Does C++ support high-quality programming or is the needless and unfruitful complexity of the language an obstacle for high-quality programming? Is there a realistic way to reduce that complexity?

Flat View: This topic has 54 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: CodeSynthesis XSD Release 2.3.1 - open-source XML Schema to C++ compiler Previous Topic   Next Topic Topic: Pantheios 1.0.1 full release approaching; beta 17 just released


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use