Weblogs Forum - Pardon My French, But This Code Is C.R.A.P.

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Pardon My French, But This Code Is C.R.A.P.

61 replies on 5 pages. Most recent reply: Jul 20, 2007 6:03 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 10:39 AM

> My point was that other engineering disciplines have
> figured out those things because they've been around for a
> longer period of time. A civil engineer projecting a mile
> long six-lane bridge must be certified. A software
> engineer projecting a life-critical or hazardous system is
> not required to be certified. I think that should change.

Completely agreed on life-critical or hazardous systems.

> > > Certification by itself indeed will not enforce
> > anything.
>
> > Producing reliable and maintainable code requires more
> > than certification.
>
> Exactly what I've said (see quote above).

Sorry, I couldn't derive from your quote that you meant the same thing I wrote.

> As for what's wrong with code and also why, I recommend
> "The problem with programming" interview with B.
> Stroustrup. He pretty much listed the main problems with
> programming today:
>
> http://www.technologyreview.com/Infotech/17831/

Thanks for the link. Having not read this interview (yet), but having read others of his, I can guess that he considers a lack of education and training for those in the field to be a large problem...and I agree.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 10:52 AM

> However, the difference pointed out between civil and
> software engineering is critical. Civil engineers solve
> problems whose solution is bound by immutable physical
> laws. Software engineers solve problems whose solution is
> not even determinable, e.g. asking a user whether or not
> to save a change implies the developer cannot determine
> the user's choice. The "soft" in the software makes it a
> different discipline from, for example, civil engineering.
> Users of our products have the ability to change
> requirements on the day of implementation based on a new
> business line. Two cities needing a bridge between them
> cannot suddenly partner with another neighboring city at
> the last minute and decide that a tunnel needs to run from
> the middle of the bridge to the 3rd city.

This is turning into a thread hijacking, but I beg to differ
with this statement. While a developer can not determine the user's choice, it certainly must determine all possible choices and offer them to user.
As for the bridges, while a tunnel to the neighboring town might be out of question, still I don't have to go far to find a adequate example. Wwhen driving home across Ravenel bridge in Charleston SC, it forks into two exits at the end, at which point I, the user, choose which one to take. And last but not least - prior to having this newest bridge built 2 years ago, there were two old bridges crossing the Cooper river - one built in the 1920's, the other in 1950's. They both were knocked down after the new bridge was built. As it turns out, the requirements do change and scalability is an issue for bridges, too.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 12:49 PM

Apropos bridges, they have bugs, too:

http://www.myrtlebeachonline.com/575/story/129455.html

It's the bridge from my previous post. However, I believe that folks fixing this will likely be able to find their way through the drawings much easier than we are finding ours through other people's code.

The bottom line about the certification is that it certainly is not a cure-it-all by itself. That being said, most people still would not consent to a surgery by an uncertified surgeon or drove over a bridge designed by an uncertified engineer.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 2:15 PM

> It's the bridge from my previous post. However, I believe
> that folks fixing this will likely be able to find their
> way through the drawings much easier than we are finding
> ours through other people's code.
>
> The bottom line about the certification is that it
> certainly is not a cure-it-all by itself. That being said,
> most people still would not consent to a surgery by an
> uncertified surgeon or drove over a bridge designed by an
> uncertified engineer.

Agreed that coding can be (much) better and certification in some areas of software development, e.g. life-critical systems, should be mandatory.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 2:25 PM

> As for speculation and taste, that falls in the
> architecture area and as we have witnessed since the GOF
> book was published up, there's a wide common ground in
> that area, too. That being said, in his last series of
> works (The Nature of Order), Christopher Alexander argues
> that there is actually the exact measure for goodness of
> design, i.e. it is not a matter of taste. But getting into
> that is beyond the scope of this discussion.

While there may be "common ground" with respect to GOF patterns that's not the same as a consensus. Like many "mythologists" the GOF targets mainstream projects and builds many patterns around the idea that certain kinds of architectural changes will be needed in the future of an application. That is often true, but not always. To be fair, they don't take as strong a pro-patterns position as some of their supporters.

Interestingly, my wife is an architectural designer and knows some of the people who worked with Christopher Alexander on a project in Mexico. He applied his "non-subjective" rules on the project, but a few years later, most of the residents eliminated the open transition from private to public space by enclosing their private areas. Apparently, they didn't get the memo on how they were supposed to behave.

I think both Alexander and the GOF have made significant contributions to their respective fields, but context is always more powerful than fixed rules.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

No hidden meaning in "mythologists"

Posted: Jul 18, 2007 3:33 PM

Apparently, my sloppy use of the gmail spell-checker turned a misspelled version of "methodologists" into "mythologists". It wasn't intended to suggest that GOF patterns are built on myths.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: No hidden meaning in "mythologists"

Posted: Jul 18, 2007 5:12 PM

> Apparently, my sloppy use of the gmail spell-checker
> turned a misspelled version of "methodologists" into
> "mythologists". It wasn't intended to suggest that GOF
> patterns are built on myths.

It was a pretty amusing interpretation of their work. You should have just left it alone! :-)

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 8:29 PM

Calling someone a software engineer doesn't make coding engineering. After all, I could equally call myself a software wizard, a software artist, or even a code monkey.

There were differing views as to whether there is a black and white thing as good code.

That question itself is an oversimplication, and ignores the code quality work that Glass and others did in the early 1970s. There are are clear quality factors (coherence, modularity, complexity, correctness) and the example, which shows a trade-off, is a reasonable example. It embarrasses me to see examples of a 3000 line method in new code when David Parnas published his "On the Criteria to Be Used in Decomposing Systems into Modules" paper 35 years ago!
Unfortunately software development, as a body of knowledge seems to forget hard-earned developments only to relearn them decades later.

The nub of the problem isn't really differing (valid) views of what good code is. It is the widespread ignorance about good code, encouraged by poor examples in textbooks and in published applications. If a developer never sees good code in their career, how will they learn?

Crap code sucks but it is also very common, even in influential software projects. It is upto us to change this. Our customers won't demand it.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 8:34 PM

Jeff disputed there being a "common ground". If Sturgeon is correct then any consensus view is a crap view. A correct understanding of "good code" must, by definition, be a minority, elitist view; a consensus view must be a banal view.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 11:00 PM

> Jeff disputed there being a "common ground". If Sturgeon
> is correct then any consensus view is a crap view. A
> correct understanding of "good code" must, by definition,
> be a minority, elitist view; a consensus view must be a
> banal view.

The consensus of scientists is that theories like quantum mechanics and relativity are valid theories. Apparently, they must be "crap science" because only elitist theories are worthwhile.

Seriously, I don't understand the casual relationship between what percentage of people believe in something and its probability of being valid.

What I mean by a consensus view is that the theory has been tested by a representative group of practitioners on a broad range of projects, using a broad range of computer languages.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 19, 2007 3:57 AM

> Interestingly, my wife is an architectural designer and
> knows some of the people who worked with Christopher
> Alexander on a project in Mexico. He applied his
> "non-subjective" rules on the project, but a few years
> later, most of the residents eliminated the open
> transition from private to public space by enclosing their
> private areas. Apparently, they didn't get the memo on how
> they were supposed to behave.

Recently, I happened to attend my home town ( http://www.krkinfo.com/Slike-htm/omisalj-slike.htm ) municipal meeting initiated by conservationists in order to prevent devastation of architectural heritage. The topic was devastation of the historic town kernel by interventions such as satellite antennas and air conditioning units on historic facades. And the folks doing these things actually did get the memo. Folks just don't care, thus the meeting. They want to watch TV in air-conditioned rooms, like you and me do. During the last couple of centuries, not only did architects got out of touch with folks, as Alexander argues. We've all got out of touch with ourselves. If you look at one picture in my link, you'll see clearly how those electric installations and horrible fence have ruined the good architecture. That's exactly how bad code ruins a good product.

> I think both Alexander and the GOF have made significant
> contributions to their respective fields, but context is
> always more powerful than fixed rules.

I agree with first part of your sentence. As for the part after "but", the whole point of patterns is that there are no fixed rules. And Alexander repeatedly iterates how whole is more than just sum of the parts.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 19, 2007 6:24 AM

> > Jeff disputed there being a "common ground". If
> Sturgeon
> > is correct then any consensus view is a crap view. A
> > correct understanding of "good code" must, by
> definition,
> > be a minority, elitist view; a consensus view must be a
> > banal view.
>
> The consensus of scientists is that theories like quantum
> mechanics and relativity are valid theories. Apparently,
> they must be "crap science" because only elitist theories
> are worthwhile.
>
> Seriously, I don't understand the casual relationship
> between what percentage of people believe in something and
> its probability of being valid.
>
> What I mean by a consensus view is that the theory has
> been tested by a representative group of practitioners on
> a broad range of projects, using a broad range of computer
> languages.

You're completely correct, my attempt to combine humor and make point resulted in a fatuous statement. My serious point is that there is a consensus view about some quality factors, for example that "coherence is good" or "readability is good." In turn this leads to rules of thumb like "A class should be responsible for one thing only", or "a method should be visible on a single screen." Now if you compare the code in "Refactoring" with that in GoF you'll see that Fowler's methods are much shorter than GoF's. This is probably a reflection of language differences, changes in style, and examples coming from different places. None of this calls into question the idea that there are some clear example sof good practice.

But here's the rub: if research suggests that the best programmers are at least 20x more effective than the average, and if collective experience is that Crap code is alll around, then there is clearly a difference between what is espoused and what is practiced.

So should we assume that everyone "knows better but writes bad code anyway?" I don't find that convincing. My experience is that when I have worked on crappy codebases, developers have been strongly attached to things remaining the same. They might say "we really should clean this up" - but do they actually know how to do that? I can recall removing 2000 lines of unneeded code and having a "chief architect" insist that I revert the change because he said boiler-plate code was easier to understand than using a method call.

I know that when I have discovered crap code I wrote I usually concluded that I did the best I could at the time and that raising issues like "schedule pressure " is just a red herring. Maybe there is a consenusus amongst experienced practicioners that isn't shared by all? Or maybe there is a wide appreciation of good code but that doesn't mean an ability to produce it?

What do you think is the root cause of crap code?

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 19, 2007 6:41 AM

They want to watch TV in
> air-conditioned rooms, like you and me do. During the last
> couple of centuries, not only did architects got out of
> touch with folks, as Alexander argues. We've all got out
> of touch with ourselves. If you look at one picture in my
> link, you'll see clearly how those electric installations
> and horrible fence have ruined the good architecture.
> That's exactly how bad code ruins a good product.
>

Let's look a this with less a human-as-center-of-the-universe point of view. If one wanted to understand basic truths about animal kingdom, would it make sense to ignore actual animal behavior or label it as "out of touch"? If, in practice, architecture doesn't resonate with the majority of people living with it, it has failed its mission. It's essentially not fulfilling its customer requirements.

> > I think both Alexander and the GOF have made
> significant
> > contributions to their respective fields, but context
> is
> > always more powerful than fixed rules.
>
> I agree with first part of your sentence. As for the part
> after "but", the whole point of patterns is that there are
> no fixed rules. And Alexander repeatedly iterates how
> whole is more than just sum of the parts.

I find that pattern supporters do often use fixed rules. How many times have we heard that a GUI design is wrong if it's not based on MVC? This may not be a GOF claim, but as is often the case, those who embrace a methodology sometimes ignore the more subtle disclaimers that the creators include.

As for Alexander, the issue isn't about how things "add up" but rather whether the general principles are universal.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 19, 2007 6:47 AM

> Calling someone a software engineer doesn't make coding
> engineering. After all, I could equally call myself a
> software wizard, a software artist, or even a code
> monkey.

What's the difference between a 'software developer' and a 'software engineer'? About $10,000 a year. My advice: call yourself a 'software engineer'.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 19, 2007 7:11 AM

> But here's the rub: if research suggests that the best
> programmers are at least 20x more effective than the
> average, and if collective experience is that Crap code is
> alll around, then there is clearly a difference between
> what is espoused and what is practiced.
>

I think the often-quoted "research" about differences in programmer productivity/effectiveness isn't really valid. What was actually measured? Was it based on production code, or a toy problem. Was maintenance, documentation, flexibility etc considered? In other words, you have to come up with a comprehensive definition of programmer "goodness" and measure it.

Flat View: This topic has 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic