Open Source Code Maintainability Analyzed

Results would be fairer by Anonymous Coward · 2005-02-15 09:31 · Score: 3, Funny

If they excluded PERL.

Re:Results would be fairer by tomhudson · 2005-02-15 10:04 · Score: 3, Insightful

"The code IS the best documentations" vs "code looks like line noise"
Anyone who has used perl knows that if you need anything beyond POD, you're not ready for perl.
Perl is "unclean" for a reason - it is there just to get the job done quickly, not necessarily cleanly.
Just try and start documenting perl - since there is more than one way to do things, you'll end up giving in to the urge to change code as you document it - so the documentation never gets written, and the code never gets finished. It's a fool's errand, a sisyphian task, the modern equivalent of a "bucket of steam". Sort of like the distraction of commenting while meta-modding.
Teach a man perl - he writes code to do the task in a few minutes. Ask him to document perl - he writes code forever - and still leaves the job unfinished.
Some tasks, and some languages, just weren't made for documentation. [tt]
Re:Results would be fairer by chromatic · 2005-02-15 10:45 · Score: 2, Funny

Helpful tip: avoid the breakfast cereal aisle of any supermarket in the U.S., lest the bewildering array of choices and your own indecision cause you to starve.

--
how to invest, a novice's guide
Re:Results would be fairer by tomhudson · 2005-02-15 10:46 · Score: 2, Interesting
... a simple, well-documented Perl script ...
If it's simple, it doesn't need documentation (remember the bad old days when people insisted on commenting every line of assembler - akkk! :-)
Me, I prefer the "Mobster" approach for perl - no comments:
1. use half-decent variable names - that solves most of the problem about "wtf does this do"
2. if it's more than a few lines, include code so that if it's run w/o parameters it prints out a "usage: ..." message
3. I'm not building for eternity - just cut'n'paste, and change code as required to do what I want to do right now.
If I wanted something /better/more permanent/elegant/, I'd write it in c. But I wouldn't want to show perl scripts to anyone - they're just fugly no matter how you slice them. And that ugliness sometimes oozes out into the surroundings. Look at the colour scheme at it.slashdot.org. Is it any wonder so many people "fix" it by typing "shit.slashdot.org" instead?
[tt]
Re:Results would be fairer by knipknap · 2005-02-15 11:52 · Score: 2, Insightful

Just try and start documenting perl - since there is more than one way to do things, you'll end up giving in to the urge to change code as you document it - so the documentation never gets written.

Is there any other language that has an equal amount of code equally well documented? CPAN has the best documentation of reusable code in comparison with other languages. Sure, there's always a bad example, but seriously, saying that documenting Perl is hard is certainly far from the truth. -Samuel
Re:Results would be fairer by BlueCodeWarrior · 2005-02-15 12:11 · Score: 2, Informative

Speaking of CPAN, I use Acme::Bleach to ensure that all of my Perl scripts are clean, easy to understand, and maintainable.

I tried to read it but... by Anonymous Coward · 2005-02-15 09:31 · Score: 5, Funny

by Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis, Apostolos Oikonomou ...it was all Greek to me.

bah! by eggoeater · 2005-02-15 09:32 · Score: 2, Funny

I just keep my code on one 3 1/2 inch floppy.
Haven't had a problem yet....

--
$7.95/mo, 200 GB disk, 2TBxfer, MySQL, PHP, RoR.

Re:bah! by Sponge+Bath · 2005-02-15 09:48 · Score: 3, Funny

...3 1/2 inch floppy
Nothing to be ashamed of, that's a pretty average size.

Was this really a surprise? by StateOfTheUnion · 2005-02-15 09:32 · Score: 4, Interesting

Was this really a surprise? Did anyone think that open osurce software is as a general rule well documented or documented as well as many commercial projects that have project management (for better or worse) and technical writers on staff to do internal as well as external documentation?

Re:Was this really a surprise? by arkanes · 2005-02-15 09:55 · Score: 4, Insightful

In my experience, OSS is no more or less well documented than commercial, in house code. Some OSS projects have great docs. Most don't. Most in house software is poorly documented. The number of companies that actually have technical writers on staff for internal software is very, very small. Certainly I've never worked for one.
In fact, I'd go so far as to extend this to software in general. Even when the comments can really matter, like API docs for libraries, the documentation sucks as often as not. I see no advantage to OSS here, but I don't see a disadvantage either.
Re:Was this really a surprise? by Anonymous Coward · 2005-02-15 09:57 · Score: 5, Insightful

O.k., perhaps its not a surprise, but in the end the community needs to do away with the 'more eyes make better software' myth in order to move forward. In that sense, it is good that 'professionals' are now pointing out that some of the software out there is actually quite bad and that it is _not_ generally acceptable to not maintain documentation and uphold good project hygiene.

Here's a nice experiment for you:

1. Select a random project, preferably one that's slightly buggy during ordinary use.
2. Subscribe to project's mailing list.
3. Politely inquire if the project has any kind of automated test suite.
4. Observe stumped reaction.
5. Kindly explain the absolute necessity of such a system in any non-trivial app.
6. Go down in flames.

That attitude needs to change.
Re:Was this really a surprise? by Feztaa · 2005-02-15 10:14 · Score: 4, Insightful

I'll probably get flamed for this, but at least with OSS, if there's no documentation, you can at least read the code to see what it does. I know, that's no substitute for proper documentation, but with closed source, if there's no documentation, you're just fucked, plain and simple. In OSS, if there's no documentation, you can read the code.
Re:Was this really a surprise? by Rei · 2005-02-15 10:21 · Score: 5, Informative

Well, the importance of a test suite rises dramatically with the complexity of the project. The difficulty of making a test suite increases with the amount of hardware that you need to implement it. When I think of "big" open source projects that aren't very hardware dependant - for example, ITK (the Insight Toolkit), they tend to have nice test suites. Naturally, the little ones don't, but little projects of most things don't have test suites.

I agree, though, that automated test suites are underused. Also, not enough programmers (OSS or otherwise) seem to understand the importance of refactoring.

A message to coders: People, if your function is more than 10 lines long, you should start to consider splitting it. If it's more than 100 lines long, you're probably doing something wrong. If you have the same code written with slight modifications two or more different ways, you're probably doing something wrong. Use templates rather than repeating code if your language supports them. If you ever feel "this should probably be commented more", don't comment it - split it up into functions and let the functions be their own comments (if you have to, comment the functions as well). Use const as much as physically possible (in supporting languages). Use array objects that clean themselves up instead of arrays allocated on-the-fly whenever physically possible. If you find certain variables being used often together, group them into an object. If you find a set of functions operating on an object and only that object, make them member functions. Etc.

Just doing basic refactoring can make code far more organized and readable.

--
"Well, then fire it up and show me what this..." (sigh) ... "coccoon can do."
Re:Was this really a surprise? by Mr.+Slippery · 2005-02-15 10:48 · Score: 2

3. Politely inquire if the project has any kind of automated test suite.
4. Observe stumped reaction.

Thing is, you're also likely to get a stumped reaction if you made such an inquiry about a random proprietary project.

--
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Re:Was this really a surprise? by tomhudson · 2005-02-15 10:58 · Score: 3, Insightful

If it's more than 100 lines long, you're probably doing something wrong.
If a chunk of code can't fit on one page (two, max) it's too damn long. You're trying to do too much in one spot, and the goonies and golems will bit you in the ass.
If it needs more comments than code, it's a sign its overly-complicated and you need to rethink what you're doing and how you're doing it. In other words, your algorithm sux the bag.
If you can't write test cases for it because it's too tightly coupled to the rest of your code, you probably misunderstood the problem in the first place (or at least you're approaching it from the wrong direction)...
All the comments and documentation in the world won't make spaghetti understandable or maintainable.
Re:Was this really a surprise? by zyridium · 2005-02-15 11:48 · Score: 2, Insightful

Um, sorry but slashdot cliche #4137 doesn't apply here...

I would be pretty certain that if you were maintaining code then you would have access to it...

*sigh*
Re:Was this really a surprise? by Rei · 2005-02-15 12:12 · Score: 2, Informative

> e.g., writing just one function and using a function pointer to control
> the inner loop behavior

No, function pointers are evil. Pointers themselves can make things rather nasty, although they are important in some situations. Use inheritance and virtual inline functions. Inline functions run as fast as macros, and inheritance is a lot cleaner than using function pointers.

> It is a hand-unrolled implementation of a bit-oriented run-length encoder

I'd like to see a piece of code that by hand-unrolling runs 7 times faster and can't be functionalized. I sure haven't seen one yet, and can't picture how that would even be possible.

> away from typical ideas of "maintainability" for the sake of speed

Seldom is that the case nowadays in modern languages. You sound like you're writing in pure C, though ;)

--
"Well, then fire it up and show me what this..." (sigh) ... "coccoon can do."
Re:Was this really a surprise? by Tim+Browse · 2005-02-15 12:13 · Score: 2, Interesting

If it needs more comments than code, it's a sign its overly-complicated and you need to rethink what you're doing and how you're doing it. In other words, your algorithm sux the bag.

Well, mostly, but I have on occasion documented something to within an inch of its life because the problem is quite complex, and doesn't particularly lend itself to being broken down further. e.g. I wrote some mesh silhouette code recently, that used a lot of small, smart objects to do its job, and was only a screen or two of code, but it still needed a fair bit of explanation as to what was going on.
Also, sometimes the algorithm is quite elegant, and I'm just pointing out that, yes, it does handle all those edge cases you were worried about, and here's how, etc. (That also kind of applied to the mesh code I mentioned.)
But mainly I'm worried about the advice being given in a few posts of "don't add more comments" - these are OSS coders we're talking about - don't give them any ideas. :-)
Sorry - spent today trying to understand a bunch of OSS code that was very complicated, and that has, by its very nature, lots of wrinkles and interdependencies, but of course, almost zero comments in the code. I can only assume such people only ever work on one project at a time - I don't know how I'd ever manage to come back to such a project.
As an aside, I considered implementing a plug-in for the OSS project, on my company's time, that I could submit back, and would be of use to other people, but in the end, it was just way too involved and complicated, so I hacked up a quicker solution.
Basically, I'm a bit tired of opening up the code of some OSS project I've got interested in, only to find that the only comments are the GPL boilerplate blocks at the top of each file :-(
(I know, I know, it's free, I shouldn't moan, etc. But take that example today - that project could have had a few days' time from a developer with 15+ years experience, implementing a solid, tested new feature, but because the overall docs (ha! as if!) and comments were sorely lacking, that didn't happen. I'm just saying. Flame away!)
Re:Was this really a surprise? by merdark · 2005-02-15 12:35 · Score: 2, Insightful

So, you are claiming that the sample of companies you've worked for represents a fair sample of all software companies? You have also looked, in depth, at the same number of open source projects and can claim that that number is representative of all open source projects?

If you are going to use your own experience as justification for your point, you should at the least state exactly what that experience is. It would be nice if you could also compile some statistics on the total number of open and closed source companies so that you can support your claim that your experience is representitive of each camp.

If you can't or won't do this, please do not presume to speak with such authority.
Re:Was this really a surprise? by Weirsbaski · 2005-02-15 14:07 · Score: 3, Insightful

... but at least with OSS, if there's no documentation, you can at least read the code to see what it does

... In OSS, if there's no documentation, you can read the code.

And if it not OSS, then either you have access to the code (in which case you can read it also), or you don't (in which case maintainability isn't even the issue, because there isn't any).

Whether the source is open or closed has no (direct) bearing on how good the source and documentation are, for those allowed to see the source and documentation.

--

I am not a sig.
Re:Was this really a surprise? by Arkaein · 2005-02-15 17:26 · Score: 2, Interesting

Sorry, while I agree with the general thrust of this your 10 line rule seems overly pedantic and ultimately counterproductive.

Often I have written largeish functions such that while they could be broken into smaller functions, at the time there would be no purpose in doing so except to enforce the "only short functions allowed" rule. In other words the small functions would only be called from a single point in the code. In situations like this recursively breaking a function into smaller functions adds function call overhead which impacts performance, but more importantly adds additional whitespace and boilerplate function definition code to the source that can detract from readability. This is especially true if a developer has to mentally step through every line of code in a function: if the function is monolithic the step through is basically linear, while if the function is heavily subdivided the developer must jump back and forth in the code to follow the chain of execution.

Yes, yes, ideally each function should be tested and verified individually, but if a function was custom coded for a specific purpose only to be used in one larger function then this is often difficult to do, due to lack of alternative test situations.

It is often the case that a chunk of code that is only useful in one location early on may be useful in multiple places later, but I believe it is best to wait until this time to refactor the original code into smaller, more modular functions.

--
The ultimate plays for Madden 2006
Re:Was this really a surprise? by Omega+Blue · 2005-02-15 20:45 · Score: 2, Insightful

I agree, though, that automated test suites are underused.

Automated test suites are vastly overrated. If all your subprograms have cleanly defined functions, cleanly defined I/O, and are small enough, it is very easy to run them through a few critical test cases.

Some people even gone so far as to substitute automated testing for clarity in design - the so called Test Driven Design. That seems like a recipe for disaster to me.
Re:Was this really a surprise? by Peeteriz · 2005-02-15 20:49 · Score: 3, Interesting

In the enterprise, for example, financial companies, is quite common to be writing and maintaining additions/modifications to some huge software package that your company has bought - you write routines that run together with their code, there are facilities for such modifications/additions.

However, you can't *really* know how *their* code works - you must interoperate with this code, but their code has (a lot of) bugs and is poorly documented - there is a lot of documentation, but it mostly covers the trivial parts, and if you *need* to know the exact behaviour in some tricky situation, then trial-and-error is the only way.
And of course, you have no access to their source code.
You may pay a huge sum of money and get that access, but the amounts involved are ridiculously huge.
You may request a change from them - but again, the costs are huge - for a trivial change they charge so much that you can fund a programmer man-year in-house - so in-house workarounds are the way to go.

Extremely Ridiculous Publishing by bperkins · 2005-02-15 09:33 · Score: 3, Interesting

GNU General Public License (GPL)
Berkeley Software Distribution (BSD)

are all defined in the article.

But not ERP.

Go figure.

At least... by BJZQ8 · 2005-02-15 09:33 · Score: 4, Insightful

At least with Open Source Software you CAN maintain it if necessary. With closed source, there is no way to make any changes to old software...and much too often, the companies that make some of the obscure CAD stuff (my field, once) are out of business. At least having it open makes it possible to change something...even if you don't.

Re:At least... by pclminion · 2005-02-15 09:42 · Score: 2, Interesting

At least with Open Source Software you CAN maintain it if necessary. With closed source, there is no way to make any changes to old software
Sure you can. It's easy to forget, but there are people who are fluent in assembly language and can figure out a defunct, proprietary piece of software if necessary.
I agree that it barely meets the definition of "maintainable," but it can be done with some effort. I've done it myself, while trying to find a problem in one of our distribution binaries -- the bug I was trying to squish went away when we did a recompile for some obscure reasons, so I was forced to hack the binary itself in order to insert some debugging hooks. It can be done.
Re:At least... by micromoog · 2005-02-15 09:56 · Score: 2, Insightful

It can be done.
But it's usually illegal. The copyrights to that program are still owned by somebody somewhere, collecting dust and mold.
Re:At least... by Anonymous Coward · 2005-02-15 09:57 · Score: 5, Insightful

As a software engineer, I do like to point out something to you. "At least with open source you CAN maintain it if necessary" is not true! Maintenance takes up a good 60+% of a software cycle. Doing maintenance requires good documentation, fixing a bug is a minor issue, especially when it's easy to track down. Understanding design decisions, understanding architecture so that you can extend the software is a big challenge.

Without appropriate documentations, you end up doing what has been done all over again, studying the software to understand how it works, which can be taxing. Go look at somewhat complex OSS projects, try hacking gcc to spit out a different binary format without reading any documentation. Try understanding postgres without documentation. GUI applications like a CAD system are even harder to make sense out of. If you are actually talented enough, the sheer effort you will poor into understanding the system, you might as well spend it designing from the ground up.

Most people are not hackers, If they were, why would they need source code? crackers don't need source code to add functionality to any system, it's a matter of patching the object code, having a section of the code jump to your own code and return. But it's ugly, having source code makes it a little bit prettier but not much.

Documentation is the key! .segmond
Re:At least... by pclminion · 2005-02-15 10:00 · Score: 3, Insightful

I don't see how copyright applies in this case. I can take a book, mark it up, cut pages out and paste new content into it. It's my book. I would be in trouble if I wanted to then sell that book, but I'm not trying to. Why should a piece of software be different?
Re:At least... by charvolant · 2005-02-15 10:06 · Score: 5, Insightful

At least with Open Source Software you CAN maintain it if necessary.

Sort of ... kind of ...
There comes a point where, particularly without design documentation, the bar is raised so high that the effort involved in maintaining something is more than that involved in moving to a new product. There's a scaling problem here. What works with small, simple direct programs doesn't work with large, complex or indirect programs.
And some OSS code is simply completely undocumented, not even a comment -- apart from the licence. Something I discovered wandering through the XFree86 XKB code.
See http://firstmonday.org/issues/issue4_12/bezroukov/ index.html for a discussion some of the weaknesses of the open source model when it comes to program comprehension.

Bleh by Neil+Blender · 2005-02-15 09:35 · Score: 3, Interesting

One need only peruse the source code of 5 randomly picked source forge projects to figure this one out.

Re:Bleh by pclminion · 2005-02-15 09:53 · Score: 3, Interesting

One need only peruse the source code of 5 randomly picked source forge projects to figure this one out.
Yeah, but don't blame it on OSS. This is simply another embodiment of the long-tailed distribution of human stupidity. In any human endeavor there are a large number of people who are Unskilled and Unaware of it. These people will try their hand at whatever catches their attention, and the results usually range from mediocre to terrible.
There's a lot of really bad fan fiction out there, too. And terrible amateur cartoons. And naive, uninformed political opinions.
What we witness on SourceForge is merely a demonstration of the inability of most people to accomplish anything of any importance. Nothing specific to OSS.
Re:Bleh by pclminion · 2005-02-15 10:03 · Score: 2, Insightful

I'm sure you could pick 5 random closed source commercial projects and find (nearly) the same thing.
The difference, though, is that commercial products can't exist (or at least by all economic rights SHOULDN'T exist) without a userbase. SourceForge is littered with stuff that's so bad it's completely unusable. You can't get away with that with a commercial product, although that doesn't necessarily mean the project is MAINTAINABLE ;-)
And I didn't think you were blaming OSS, just picking up your thread and running with it.

This assumes commercial software is any better by Augusto · 2005-02-15 09:36 · Score: 4, Interesting

And it's often not.

Many of us have and are working in the "real world" out there, and I've been less than impressed with most documentation on large products.

Not to mention design documents, which end up being dead documents that are outdated as soon as the first line of code is written. To many corporations, there's no big incentive to spend so much money on these types of activities when you can have people just churning out code and finishing the darned product in the end.

I'm not saying commericial development is any worse, but I can't say it's any better for sure either.

--

- sigs are for wimps.

Re:This assumes commercial software is any better by tcopeland · 2005-02-15 10:32 · Score: 3, Insightful

> design documents, which end up being
> dead documents that are outdated as soon
> as the first line of code is written.

So true. Or only one page will be kept up to date - the database schema diagram, because it can be automatically generated from the production database schema.

Meanwhile, new hires are referred to these documents with mumbles of "this is the design documentation, read this and you'll know everything". This statement is usually accompanied with a cynical smile and a shrug, indicating to the new hire the uselessness of the ritual. Ack.

--
The Army reading list

GUI by kaalamaadan · 2005-02-15 09:39 · Score: 2, Interesting

Not to mention interface design. Ad hoc designs could be enormously good - like Winamp - or miserable - any of GIMP, the clipboard in X, the interface specifications for internationalization.

In spite of drives towards a uniform consistent design, the OSS commmunity still has a long way to go in terms of interface design, which is the defining factor in acceptance of packages like ERP. In "The Art of Computer Programming", Knuth makes note that programmers hate I/O programming.

After nearly 35 years, it is still so. OSS remains an extreme case-in-point.

Re:GUI by Phleg · 2005-02-15 10:08 · Score: 5, Insightful

You're actually trying to claim that Winamp's design is good?

Winamp and other players which try to emulate the look and feel of a "new wave" stereo do nothing but piss me off. Stereo systems have the bad interfaces they do because of an inherent lack of physical space; something that's still a concern with computers, but much less of one.

Here's to more programs like Rhythmbox and iTunes which have the *important* controls accessible, allow for easy categorisation of songs, and use screen space nicely. All that without having to resort to 6pt fonts.

--
No comment.

Those who forget history are doomed to reimplement by Thud457 · 2005-02-15 09:39 · Score: 2, Funny

You lazy young whippersnappers and your precious Perl! You probably think you INVENTED write-only code. In my day, we wrote APL, and nobody liked it!!!!

--

the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

Ah yes. by Stumbles · 2005-02-15 09:39 · Score: 2, Funny

What more documentation do you need than the source code? Seems plenty enough to me, seeing as by and large only developers would look at it anyway. Even if a non-programmer wanted to spin their propeller on it, the original author is only an email away. Seems rather complete to me. Of course the analysis would not be complete without an equation. 43 sounds about right to me..... it's one better than THE answer.

--
My karma is not a Chameleon.

Re:Ah yes. by generic-man · 2005-02-15 09:44 · Score: 2, Insightful

Yes, but the original author is not required to answer your question satisfactorily if at all. Companies that plan a massive roll-out of an ERP tool can't rely on ad-hoc support; companies typically expect a support contract of some kind. Some Linux companies offer support contracts, but only for products which they have chosen to support.

--
For more information, click here.

Only one man... by game+kid · 2005-02-15 09:40 · Score: 3, Funny

...dared to challenge this article.

(insert rousing action-series music) Hercules!

--
You can hold down the "B" button for continuous firing.

Documentation? by Anonymous Coward · 2005-02-15 09:40 · Score: 2, Insightful

The disadvantages of OSS development include absence of complete documentation or technical support.

Yeah, it's nothing like closed source software, which always has complete documentation. I mean, look at Windows itself. All of that documentation about all of those API calls, lots of useful specifications about interoperating with the underlying kernel, plenty of specifications about the NTFS file system...

Oh, wait. It's all kept "secret". Nevermind.

Re:Extremely Ridiculous Publishing by rdwald · 2005-02-15 09:40 · Score: 2, Informative

GNU General Public License (GPL)
Berkeley Software Distribution (BSD)

are all defined in the article.

But not ERP.

Go figure.

It seems like ERP stands for Enterprise Resource Planning.

Mirror this article for closed source development. by dilvie · 2005-02-15 09:41 · Score: 3, Interesting

I'd like to see the same story aproach done for closed source projects. Since the focus here was on open source, specifically, it wasn't really well balanced, and it didn't tell us anything new. Anybody who's browsed sourceforge could have told you that open source development has its share of problems.

The real question is whether or not closed source projects are all that better off.

--
MakePassword.com Mp3 Blog

Disadvantage? by null+etc. · 2005-02-15 09:43 · Score: 2, Insightful

The disadvantages of OSS development include absence of complete documentation or technical support.

And this differs from commercial software, how?

I've spent 20 hours trying to figure out how undocumented or broken features behave in Rational's Enterprise Product Suite 2003. And that's expensive software.

I'll choose the software whose source code I can examine any day of the week. Granted, I'm a developer. But it's much worse to lack both documention and source code.

Experience may vary... by moz25 · 2005-02-15 09:46 · Score: 2, Interesting

The more high-profile OSS projects mostly do have quite extensive documentation and various mailingslists and forums to support it. Plus, if official support is lacking, it is always possible to get some sort of support from a third-party company as they have exactly the same access to the software as the original developers. With other words: the spectrum of support you *can* get is much larger, even if the support you *do* get (on the smaller) projects may be lower on average.

--
see a Text Widget

No suprise, some projects are best suited for OSS by segmond · 2005-02-15 09:47 · Score: 3, Insightful

It takes being interested in a project for one to pour himself into it. Most hackers/programmers have a thing for Operating System and programming tools, So it's not suprise that OS projects are doing betters. Or Programming tools, GCC, editors, Programming Languages, Databases... I love to program, but I could never find myself programming an ERP system, just for some company to make money of. How is it going to meet my personal need? There has to be something in it for me!

This is why accounting software, office software and lots of general use applications "suck" in the OSS word. The "motivation" is not there, even "ego" is not a good enough motivation. My fellow hackers will give me more props for some lousy 500 line python hack which does something weird and not so useful than a complete accounting software suite.

What would be interesting is to see a group of companies start an OSS project from the ground up, pour their own money, pay programmers. But then again, there is no motivation for that! Big companies are only interested in jumping on OSS projects that happen to have gained fame...

--
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind

You don't want to know what goes into sausage by melted · 2005-02-15 09:48 · Score: 4, Informative

I've worked on a major product in CRM market, and let me tell you, don't want to know what goes into sausage. If you knew, you wouldn't touch this code with a 10 foot pole much less bet your company on it.

I'm sure it's the same with ERP. It's just a huge polished turd, but because you don't have the source code you don't know it's a turd. You only see the polish.

Re:You don't want to know what goes into sausage by Skuld-Chan · 2005-02-15 18:46 · Score: 2, Informative

I'm on the support side of a crm product and I totally believe you.

Its often a case of fix one bug create 2 more. We've got customers who refuse to upgrade because they are worried about losing data, running into strange bugs that didn't exist in previous versions etc.

I think a lot of stems from the fact that developers of this stuff tend to focus on putting new features in the program rather than stabilizing or documenting it.

ERP by fatcowtoes · 2005-02-15 09:50 · Score: 3, Insightful

However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.

Yeah, it's also still questionable whether systems like ERP can be developed successfully at all. I'd like to see statistics on the number of ERP implementations that go horribly wrong and wind up crippling or even bankrupting companies.

Guess we'll find out. by Brent+Nordquist · 2005-02-15 09:51 · Score: 2, Informative

However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.

GNU | Enterprise

--
Brent J. Nordquist N0BJN

Why not open-source ERP? by SharpFang · 2005-02-15 09:52 · Score: 2, Insightful

No joking here. An old question, what's the best accountant's answer to "how much is 2+2" is "whatever you'd like it to be."

Custom Enterprise Resource Planning software sometimes includes parts no boss would want the IRS or other authorities to know. With Open Source they become blatantly obvious. In this case Security Through Obscurity is the only safe model.

Sure a HONEST resource planning software can be open source. But it won't ever make the company as successful as one with some... extras.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

In theory... by the_skywise · 2005-02-15 09:56 · Score: 3, Interesting

I always thought that if you have enough people "chewing" (working) on the same module that it should eventually self-standardize into a least common denominator of maintainability. Which, if not the most maintainable code, should be as maintainable as possible given the design and interoperability constraints (with other modules). Evolutionarily speaking... it HAS to be maintainable or it "dies" (becomes unmaintained and then unused or superceded by another implementation).

On the flip side, a closed source module could be built "top down" to a unified set of coding standards that would help maintainability. But it's not a requirement. I've seen plenty of code bases built just this way that were horrific... But still maintained and not changed because management was willing to throw enough money to keep things going (but not enough money to make it more interoperable).

YMMV.

maintainability index = bullshit by idlake · 2005-02-15 09:56 · Score: 2, Insightful

You can find a description of the maintainability index here.

If you look at the desription, you'll see that the equation was mainly "calibrated" based on a bunch of projects at HP. But fitting such an equation to a handful of self-selected projects doesn't give you any idea of how statistically valid it is.

Furthermore, the maintainability index contains measures that you would expect to go up as software systems become bigger; therefore, it isn't even a meaningful comparison of software systems of different size (or a single software system over time): maintaining a 1MLOC project is just a lot harder than maintaining a 100kloc project, but you may be doing equally well on both of them.

Particularly amusing is a term of 50 * sin (sqrt(2.4 * perCM)) in the maintainability index, where perCM is the average percentage of comment lines per module. As perCM ranges from 0 to 100, the argument for the sin(.) function will range from 0 to 15 (ponder for yourself what that means about how much you should comment).

Until someone produces sound maintainability data with hundreds of software projects, the use of MI is just bullshit.

Re:maintainability index = bullshit by pclminion · 2005-02-15 11:04 · Score: 4, Insightful

Particularly amusing is a term of 50 * sin (sqrt(2.4 * perCM)) in the maintainability index
It's only amusing to people who don't bother to think about why it's there. It's actually a very insightful part of the metric.
First of all, perCM ranges from 0 to 1, not 0 to 100. Yes, that isn't explicitly stated, but it would be ridiculous otherwise. Second, try looking at the damn graph.
As I told somebody else, do it now. Don't pretend to do it, GRAPH the damn thing and look at it: sin(sqrt(2.4*x)) for x=0..1.
That graph makes it completely transparent what they're trying to accomplish with that part of the formula. First off, if comments are 0, the value is 0. Having no comments does not positively impact maintainability! Second, the function PEAKS at around 0.43. This represents an avgCM of 0.03, or 3%. Then, the function begins to go down again, but not as drastically as it rose.
What this is saying is that the benefit of comments has a maximum at around 3%. Having more comments than this tends to DECREASE the maintainability (and this is borne out by experience). However, having too many comments is better than having too few comments, so the function is skewed to the left side by the sqrt() function.
You see, every part of that expression makes total sense if you spend more than 2 nanoseconds thinking about it. Sheesh.
Re:maintainability index = bullshit by pclminion · 2005-02-15 11:37 · Score: 2, Informative

Oh, it is quite explicitly stated: perCM is described as a "percentage" (as in "per hundred"), so it ranges from 0 to 100, not 0 to 1.
The etymology of the word is irrelevant. In practice, people use the term "percentage" to mean parts-in-100 OR a fraction. Look at the second definition listed in the dictionary. It's a "part of a whole." I've used it both ways many times. So has every engineer I've ever worked with. It's usually obvious from the context, as it was in this case.
Well, what you illustrate again is that the MI is a seat-of-the-pants kind of measure that was thrown together because it looks nice, not because anybody thought about statistical validity.
Do you even know what the term "index" MEANS? It's a magical number used to quantify the unquantifiable! It's dimensionless! What, do you think the Consumer Price Index is any less black magic? Nobody ever implied that the number has any statistical validity, it is just a number which happens to do a fairly good job at helping people compare things.
If it's useful to you, use it. If not, don't.

were you reading the same paper? by idlake · 2005-02-15 09:58 · Score: 2, Interesting

From the conclusions:

Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality.

So, apparently, the authors think that OSS is as a general rule better than CSS from a maintainability point of view.

Open Source ERP by stiller · 2005-02-15 10:03 · Score: 5, Interesting

However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.

I could be mistaken, but isn't Compiere an established OSS ERP implementation?

I think the questin shouldn't be: 'Can software like ERP be developed as OSS?' But rather: 'Are there enough people in the OSS community interested enough to develop this kind of software without any form of financial support?' I think the answer has turned out to be 'no'. The same goes for things like (good) financial software, and anything that would require heaps of work, high precision and coordination, but no spectaculair result for the common man to brag about.

Re:Design docs by miu · 2005-02-15 10:05 · Score: 2, Insightful

Required javadoc/doxygen/VCS comments often result in "XXX: required for checkin" type comments.

Not knocking inline documentation - I think it is a great idea, but you have to make sure that developers buy into it.

Really there is a lot of common sense that can go into coding standards to help reduce recurring bugs in "problem functions". Rules for initializing and using globals, rules for maximum method length, code ownership, and small group code walkthroughs can do a lot to prevent the kind of problems you mention.

--

[Set Cain on fire and steal his lute.]

Corporate OSS is an Ad-hoc Corporate Alliance by Mr.+McGibby · 2005-02-15 10:06 · Score: 3, Insightful

Good corporations understand the value of corporate alliances. Often, the cost of doing something by yourself isn't worth the payout. Business support software is one of those. Companies don't make money from selling their internally developed software. OSS provides a means for lots of small companies to get together to create this kind of software, without having to create a formal agreement. Sure, some companies are going to take advantage, but if it is open, then every company can add the features that it wants.

The problem with a software company filling this role is that their system is proprietary and unmodifiable by the client. Most companies *do* have the resources to hire a programmer or a contractor to add a feature to a piece of OSS.

Anyone have any ideas on how to prevent abuse of such a system? That is, too many people using the system and not enough people contributing?

--
Mad Software: Rantings on Developing So

Re:Corporate OSS is an Ad-hoc Corporate Alliance by rjstanford · 2005-02-15 11:14 · Score: 2, Informative

The problem with a software company filling this role is that their system is proprietary and unmodifiable by the client. Most companies *do* have the resources to hire a programmer or a contractor to add a feature to a piece of OSS.

Not quite. Most enterprise software comes with source available, and pretty much all of it gets customized once you get into bigger customers. Its actually a real PITA when it comes time to do upgrades. And yes, I'm an architect at an ERP vendor.

--
You're special forces then? That's great! I just love your olympics!
Re:Corporate OSS is an Ad-hoc Corporate Alliance by Ogerman · 2005-02-15 16:24 · Score: 2, Interesting

Anyone have any ideas on how to prevent abuse of such a system? That is, too many people using the system and not enough people contributing?

In my experience, you can't worry about the people who don't contribute. It's their own loss -- though most will realize with time that it isn't worth the cost of maintaining private forks.

The business decision for OSS is always a very calculated one. It comes down to this: after investing in development of any necessary improvements to an OSS package, are you still saving money? The answer is often different depending on the term -- such as in the case of a less-mature project that needs more work. It is easy to envision a world where the short term costs of choosing OSS are always cheaper because everyone else has already done the majority of the work. But this is not where we are at today. As a result we need a maximum of cooperation with the realization of those involved that the beginning stages are the roughest and most expensive. Perhaps this is why we've seen the most OSS involvement from larger companies -- they have the resources to think longer-term and take more risks. For the rest, we probably need more heavily commercialized OSS business software to spread the load/risk.

I wish people would stop talking about... by m3741 · 2005-02-15 10:08 · Score: 2, Interesting

the lack of technical support for open source software. I have gotten more help on more issues by searching Google than I have EVER gotten from some "central" help center for any closed source application.

Re:Extremely Ridiculous Publishing by Bozdune · 2005-02-15 10:08 · Score: 4, Insightful

Right, and what the hell does "Enterprise Resource Planning" mean?

It used to mean the combination of MRP ("Material Requirements Planning") + Accounting. Then along came PeopleSoft and kinda changed it to HR + Accounting. Then along came Siebel and everyone scurried to make it MRP + HR + accounting + CRM (not quite there yet, though). Then they noticed Kronos and they all scurried to make it MRP + HR + Accounting + CRM + Time & Attendance. And failed, because Time & Attendance is a big pain in the butt. Heh. So they partnered with Kronos instead.

The march of "embrace and extend" continues. Next app up: Expense Reporting (say bye-bye to Concur, etc., that's an easy app). Already on deck: data warehousing (say bye-bye to Cognos, Business Objects, etc., say hello to SAP BW). Soon to come: business process automation (say bye-bye to Ariba, etc.)

And so on, if you believe the pundits.

"ERP" has become a meaningless acronym, an umbrella under which every business app known to man is rammed into the same stinking pile of multi-million dollar shit. At some point it will probably implode from its own weight, and we'll go right back to the "best of breed" interoperable software model.

But it will be a while yet. I suspect in the meantime there will be some Open Source alternatives. I sure hope so.

bah! "experts" by Anonymous Coward · 2005-02-15 10:12 · Score: 2, Funny

From TFA: "Four computer scientists ... argue that Open Source software development should..."

I stopped reading at that point.

If they think they're so smart, those 4 guys are welcome to fork whatever project they want and do it themselves.

Sin(Sqrt(comments_in_percent)) ??? by phkamp · 2005-02-15 10:15 · Score: 2, Insightful

Have you guys looked at the formula ?

They take sin(sqrt(mumble_percent)).

Now, I'm all for emperical data, but that is just bistromatics and totally insane.

They don't even say if the argument to the sine function is in degrees or radians and one is left to wonder if they even know themselves...

I have no doubt that if you take a piece of code and does a before&after check after some major rewriting it may tell you something.

But comparing two different pieces of code with this formula is just plain bogus.

Poul-Henning

--
Poul-Henning Kamp -- FreeBSD since before it was called that...

Re:Sin(Sqrt(comments_in_percent)) ??? by pclminion · 2005-02-15 10:49 · Score: 3, Informative

They take sin(sqrt(mumble_percent)).
Now, I'm all for emperical data, but that is just bistromatics and totally insane.
Metrics are already "black magic." This one is no worse or better than any other dimensionless metric I've seen.
Obviously the input is in radians. The argument to a trig function is always assumed to be radians unless otherwise specified. Now, the sqrt(mumble percent) can only range from 0 to 1, so what we're looking at here is the graph of the sin function from 0 to 2.4 radians.
Do it now. Graph it. Graph the function sin(sqrt(2.4*x)) from x=0..1
Notice that this function (you might call it a transfer function) ramps up and peaks at 0.43 radians. That corresponds to a comment percentage of 3%. Then it begins to go down again. What does this mean? It means that there is a point beyond which more comments are not useful. If more than 3% of your code is comments, there's something wrong. That's all that part of the equation means!
You only classify it as "bistromatics" because you're too lazy to do the thinking and figure out what it's for.

Quality is still a happy user by mcdtracy · 2005-02-15 10:18 · Score: 3, Insightful

Quality is still a happy user. Users like software
the works well and hopefully doesn't need a lot of documentation to make it work well. Great software
tends to teach the user how to make it perofmr or at least motivate the user to want ot invest the time to master the software for a particular use.

These guys need to understand that this approach to quality applies to all software, irrespective of
development model behind it. A software product with a lot of customers creates the momentum to maintain and enhance that product. An OSS product can be infused with similar energy due to acceptance by a large community of users (esp if many are programmer's too). The feedback from the users incents the programmers to maintain and enhance the product.

New models can be built from hybrids of OSS (donated programming in the commons) and products
that one must buy. If there emerges an ERP OSS app then there will be a business opportunity to document/train, support/fix/enhance/customize that application... and Oracle will feel the same frustration competing with that model that MS does competing with Linux.

These complaints against OSS as a model (no obtion to buy support or docs) are a business opportunity
that has been put into play by JBOSS, MySQL, and soon to be hundreds of others. The low barrier to entry is the key to high usage... It's try and don't buy (unless you'd like some training, customization, focus product enhancements, etc).

Volume, usage and effectiveness drives the software world. Quality just makes the ride more comfortable. And OSS gets more comfortable everytime the train puls through the station.

Was in "Look at the Numbers!". Positive results. by dwheeler · 2005-02-15 10:37 · Score: 3, Informative

It's worth noting that a slightly older variation of this paper was already referenced in Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! back in 2004-09-30. Look at their results, the actual numbers give a rather positive story: "1. Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality."

OSS is no silver bullet. Their last point is "OSS code quality seems to suffer from the very same problems that have been observed in CSS projects." Er, big surprise, they're all software.

--
- David A. Wheeler (see my Secure Programming HOWTO)

How many projects have died for maintainability? by coldtone · 2005-02-15 11:19 · Score: 3, Insightful

I have seen many a software project disregard performance, features, and development speed all in the name of maintainability.

We can't use JSP's, there hard to maintain!
We can't use Javascript, it's loosely typed!
We have to use an Object Broker, SQL is not maintainable!

All the projects that I have been on where code maintainability has been the primary goal have one thing in common. They all failed.

If you spend all of your time worrying about how the code looks, you will never finish the project. Talk to people who have built successful software. (The ones that sold millions of copies.) Very few of them are proud of the code the wrote, but they are happy with the product.

The focus should always be on product quality, not code quality.

The language is very important by doc+modulo · 2005-02-15 11:28 · Score: 4, Interesting

- C++ is more readable than assembler
- C# and Java are more readable than C++ ...
- At the end of this list are functional programming languages.

If you can read source more easily, then maintainability will be better.

This article will tell you why you should be interested in functional programming languages. If you're smart and open minded, you will be convinced.

The best functional languages are Haskell and Erlang (click "next" at the bottom of the page).

For example, with Java you prevent bugs by static typing variables, example:

int numberOfTries = 3;

If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it.

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables.

The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturere is going multi-core chip now. Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.

There are tons of other advantages but, as I said, the above links will convince you if you're smart. Haskell is a bit more academic in nature, they're figuring out the best possible language and Erlang is more polished and ready to go. It was invented by Ericsson to create ultra reliable realtime servers.

--
- -- Truth addict for life.

Re:Language and coding style by pclminion · 2005-02-15 11:32 · Score: 2, Insightful

It's just my opinion, but I think if people stopped using older languages like C and moved to more self-documenting languanges, things would be a lot easier. For instance, Objective-C self-documents its own methods (i.e. "[object doThis:that forThis:that];").

I don't follow. How is that any more or less clear than:

object->doThis(that);
object->forThis(that);

Are you trying to say that the former is better because it looks more like English? Weird argument to make, considering the majority of the world's population doesn't speak English as their first language, so it's irrelevant that it happens to look like English.

Any language (except maybe assembler) can be written in a readable way. You just have to learn the idioms.

Can I ask a stupid question? by rastin · 2005-02-15 11:38 · Score: 3, Interesting

Are there standard methodologies for making non-oss code maintainable? If there are its news to me, every place I've worked has been uterly bass ackwards with their source code. Redundant libraries that do the same functions (one writen by Bob the other by Fred). Documentation that is years out of date with reality. And all the dead objects floating around, (its safer to leave them in that pull them out). With non-oss you get a pretty users manual, maybe that is what people call maintainable. Not to say there can't be sloppy OSS code. I think a great topic for discussion would be just plain maintainablity, whether its OSS or not.

The article mentions doubt on whether an ERP system can be build OSS, why not? Are they planning on giving every end user the source code and ability to recompile the company's ERP? When I install Linux and friends on my mother-in-law's computer I don't plan on giving her the source code, is it implied that OSS is less maintainable because you cannot tell if someone has an altered version? It just freaking code!

A Plead For Generic Code by knipknap · 2005-02-15 11:46 · Score: 2, Insightful

I found that progress of open source software can often be measured by the availability of generic code. Once that code has been written as a generic library, collaboration is easy and higher level code is more maintainable. This is where Open Source software can have one huge advantage: Collaboration can take place on the libraries, and many applications take profit from that work *between different projects*. You have much more possibilities then in commercial software projects, where you seldom share much work between companies.

That also makes generic code even more important for OS. We have seen huge progress in the last years and most of the lower level stuff has appeared or become more mature.
Unfortunately though, this is also what I still found to be the most lacking in higher level libraries. Most projects go like this:

"We need a really cool search front-end for Google. Let's see whether there's a cool library for this. Nothing yet? Ok, then let's just start from scratch."

And then a library is implemented, with an API for searching using Google. It is perfectly usable for exactly what the developer wanted.

Now this seems reasonable at first, but think about this: In OS development, we are not bound to time lines. Why should we chose a half-hearted attack on a problem that will surely hit others after us again? Instead, the developer could also ask, "if I create a generic library, how generic can I make it? Do we have to limit it's capabilities to requesting stuff from Google? Or maybe I could even create a library that allows to query any search engine? Or maybe, provide an API the lets you query anything, like search engines, your local hard disk, p2p networks and a local database."

In commercial software development, this would be completely unreasonable overkill. In OS however, it's a great way to collaborate. And once implemented, the foundation for a lot of applications has been lied. And it's also fun - writing libraries is fun. It is a great component model either. And it is also a pleasure to see when the work is done, because once the foundation was set writing the actual application is as easy as plugging components together.

There are also good examples, of course. Gstreamer is one. But there is still so much potential. I would like to see this kind of thinking more and more.

cash for quality, cheap for free by zogger · 2005-02-15 11:57 · Score: 2, Insightful

what about star office -> open office? Isn't that sort of close to what you want?

But ya, I know what you mean. I'm not a coder, just a consumer, but I would be more than willing to pay good cash (not x -hundreds, but maybe x-couple/3 dozen dollars) for an OS (once a year, not 3-4 times a year scamola) that paid all the developers, was still open source, had fewer apps but all of them *worked* and if I had a question or problem still remaining, I could go post on their bulletin board and get an actual for-real honest informed reply, from a paid company person, that answered my question or resolved the problem or at least determined that it was in fact pretty close to impossible to be resolved. Tell me the truth in other words, I can live with it. I'm getting sorta tired of "yep, we gots us a real community volunteer effort and it's gonna be the bestus and it almost works, just you wait until the next release!!11!1" stuff.

There's an open source business model that might work to sell a real joe consumer desktop and still pay the coders. I'll pay for 20 really well written apps with extensive user accessible written in hoo-mann speech docs, said apps that work and serve basic normal computing functionality for this "the masses" guy (moi and probably millions more), but I am not going to pay for two hundred or one thousand "almost works" volunteer apps on 6 cds and a dvd plus download even more!, etc , including the no credible help even if they have a so called wiki or board or mailing list or irc channel. Nope. I used to believe that but not any more. Not prudent any longer. This is 2005. We have entered the "better work right now right when it's installed" era, not the "coming soon" era, that was LAST century.

signed, joe consumer

Some languages invite a more formal approach by synthespian · 2005-02-15 13:54 · Score: 2, Insightful

Although you intented to flamebait, the joke invites the consideration that some languages make it harder to write clear specifications and some make it easier.
In Perl's case specifically, the language lends itself to quick scripting and shorthand. This is great for little tasks, but as everyone knows, it doesn't scale well. This isn't Perl's or Larry Wall's fault. It was designed to /also/ allow for "quick and dirty" style which is ideal for little tasks. If you maintain that style for larger programs, it is exclusively the fault of your lack of talent, methodology and wits as a programmer.
However, I would like to point out that some languages actually enforce a clean specification. In particular, the functional languages almost literally *force* you to it. I am thinking here of the likes of SML, Haskell, OCaml, Clean, etc. This is not the place to discuss the fact that they also have a sane type system, where others have a broken one (e.g., C - see: http://perl.plover.com/yak/typing/). Language advocacy sucks, anyway ( http://www.perl.com/pub/a/2000/12/advocacy.html).
There's this story a guy posted once on comp.lang.functional about how once he wrote a Haskell program, handed it to the manager and he said: "great, you wrote a specification, now write the program." (!) The manager actually though what was executable Haskell code was just a "spec." Haskell fully suppports Knuth's literate programming approach.
If you ever tried writing something in those languages you know how they force you to write clean code. It is simply the easier way to break code in small functions. "Factoring", I believe it's called.
My point is that I feel the OSS community could greatly benefit from non-mainstream languages. These languages have seen nearly 2 decades of intense research. Arguments pertaining to performance just don't hold anymore vis-a-vis other mainstream languages like C#, Java, Python, Perl, etc. Clean has a video-game library to prove the point (http://www.cs.ru.nl/~clean/). OCaml, SML and Clean approach C performance (Ocaml coming second to C in some "language shootouts" for most benchmarks, for all its worth). Also, some of these have been used in large "real world" problems. OCaml has been deployed in the C code verification for correctness of the flight control software for the Airbus 340 airplane, for instance (http://www.astree.ens.fr/). It is widely known that Ericsson uses Erlang for their telephony switches (www.erlang.org). The CIL - Infrastructure for C Program Analysis and Transformation is written in OCaml and if more widely known, could prevent the weekly flow of buffer overflows developed in Berkeley and can be used *right now* in large OSS projects (http://manju.cs.berkeley.edu/cil/). They've tested it in the Linux kernel, for example (whether they sent patches or not, I don't know).
Of course, you have to have an open mind, and be willing to learn and throw some old tricks out and work using a different approach/mindset. Learning things thoroughly is always hard work, but the OSS shouldn't dismiss functional languages as "academic" - and for that matter, other serious approaches, like Squeak Smalltalk, for instance.
My 2 cents.

PS: I'm no expert at programming, just a beginner, but I offer my opinion here because I feel some people just haven't been introduced to some facts and haven't heard of some stuff. Not everyone has a big company to promote their language.

--
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts

Re:How many projects have died for maintainability by Jerf · 2005-02-15 14:27 · Score: 3, Informative

We can't use JSP's, there hard to maintain!
We can't use Javascript, it's loosely typed!
We have to use an Object Broker, SQL is not maintainable!

All the projects that I have been on where code maintainability has been the primary goal have one thing in common. They all failed.

If that is their idea of "maintainable", they didn't fail because they shot for maintainable, they failed because they drank the kool-aide and trapped themselves into software paradigms that only work when oodles of resources are thrown at them. Smaller teams require more agile methods to get results, and that is also the mechanism whereby smaller teams can produce software where larger teams failed. (It goes both ways, I'm not claiming that as an absolute. But that small teams can and have beaten much bigger ones is an unassailable fact.)

Certainly you've got some good facts at hand to learn from, but I think you're taking the wrong lesson away. Projects that simply ignore maintainability fail, too. Can you imagine Mozilla with no concern for maintainability, or the Linux kernel?

The focus should always be on product quality, not code quality.

If you don't have quality code, you don't have a quality product. You may have an adequate product. You may be in a situation where an adequate product is all you need. I have an adequate set of knives in my kitchen, because I can not afford quality knives. But I do not pretend that they are therefore quality knives.

You're calling for a classic short-term focus, and you can and will suffer the classic penalties for short-term focus. I know, I've seen it first hand and dragged software products out of their local optima by the sweat of my brow. It's not easy, but either it happens or the product dies a code-quality death.

You need to use the proper metric for quality. Inappropriately using and paying for a strong type system is anti-quality in my book; that goes for your other two examples as well, when done correctly. (SQL and JSP code both need to be rationally minimized via the application of Once and Only Once, but they are not the cause of the unmaintainability; the abandonment of Once and Only Once is. Once and Only Once is one of the most important aspects of any proper quality metric.) Your quality metric should have functionality built into it.

further research indeed by famebait · 2005-02-15 20:43 · Score: 2, Funny

While they admit further research is needed,

It's not usually all that hard to get people to "admit" that they'd like more funding.

disclaimer: that was not meant as a rant, I work in science myself. But "more research is needed" is a running joke in the community. It doesn't detrect from the work, but every publication on the planet includes it, and every serious reader treats it as a mere formality and silently ignores it.

--
sudo ergo sum

Urban legend alert! by Anonymous+Brave+Guy · 2005-02-16 07:35 · Score: 2, Informative

People, if your function is more than 10 lines long, you should start to consider splitting it. If it's more than 100 lines long, you're probably doing something wrong.

So I've been told, sometimes by some of the biggest names in programming. Unfortunately, a firm belief among the industry doesn't make them right.

Rather than debunking this one here, I'll simply refer you to Steve McConnell's excellent Code Complete. McConnell cites a large amount of hard data to show that longer routines can be at least as good on both development time and error count grounds as shorter routines, and indeed exceptionally short routines (the 10-liners you're advocating) are amongst the worst on both metrics.

As an aside for general interest, since I'm sure a lot of people reading this comment also found that book very good, it seems a second edition has recently been published, updating the examples by a decade or so and putting much more emphasis on recent coding approaches, particularly OO. Whether that is an improvement remains to be seen, but I'll certainly be buying a copy. I guess if he's reversed his position based on more recent studies, I'll have to eat my words, too, but I doubt it. ;-)

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

Slashdot Mirror

Open Source Code Maintainability Analyzed

80 of 264 comments (clear)