Research question on programming language and writing software.

Question

I am looking for research papers, case scenarios etc that explain or show why less code is easier to maintain, debug, etc. Possibly how choice of programming language can affect it etc. I have no idea how to find this information. Googling something like "research programming less code" yield tons of results and the first few pages doesn't seem to have results/links that I am looking for.

Do you guys know any papers, articles or websites that may have information I need? Anything about research and saving cost on programming (outside of using middleware/having someone else do it) would be good.

Answer 1

There is a little here in the Software Reliability Handbook. I think I can see is function of lines of code and of reliability.

• http://www2.computer.org/portal/web/csdl/doi/10.1109/ICSM.2001.972723 seems (not read it) to be a case study comparing reliability to 19 metrics - I think this may be a starting point.

Answer 2

Regarding "less code", you might have better luck searching for The KISS principle.

And for a "website" that may have information you're looking for, I must recommend sifting through the works of Martin Fowler and be sure to look at his list of articles.

He writes a lot about code quality an OOP, but I believe that you might find what you're looking for there or atleast get some pointers.

Answer 3

I would reverse the process and review the "bug/LOC" data. From the misc sources I've read(none I can recall, and most uncitable), bug/LOC is loosely exponential as LOC grows.

Answer 4

I've always found this paper rather interesting. There may be more recent versions around.

Answer 5

In academic work, observed bug rates are often expressed or normalized per "thousand lines of code" or KLOC. Searching Google Scholar for combinations of software, bug, error and kloc yields numerous possible sources.

Answer 6

For what it's worth, I wrote a book on this, and discussed it on SO.

The basic idea is to apply information theory to software. Examples of modern ideas that are consistent with it are DSLs, the so-called "KISS principle", and DRY, but it goes far beyond that. In a nutshell, the fewer editing changes needed to implement average functional requirements, the fewer chances there are to introduce mistakes, and it could be argued the redundancy (as a code) of source, leading to exposure to errors, is the primary if not only source of bugs.

ADDED: Algorithmic (or Kolmogorov) Information Theory expresses the information content of something as the length of the shortest program that can compute it. I have two problems with it.

1. The theoretical work that is done with it goes off on abstract tangents that have little practical application.

2. I think what is even more important than the length of a program is the length of the sequence of edits that produces it as a function of the requirements. I don't know of any theoretical work on this aspect of it.

Basically, the idea is if a language is minimal with respect to a problem domain, then programs in that language correspond 1-for-1 with problem statements, so a program can never crash (i.e. satisfy no requirement). On the other hand, if programs contain more than that minimal amount of information (have redundancy), then there can be programs that don't match any possible requirement (i.e. they are simply wrong regardless of the requirement). The more redundant they are, the larger the space of invalid programs is compared to the valid ones. Any human errors in entering these programs is thus much more likely to produce an invalid program (that crashes or gets invalid answers).

That's why it is important to minimize the redundancy of the language w.r.t. the problem domain. That's what DSLs do, ideally. In my opinion, good programmers instinctively arrange their code so as to allow new or revised functional requirements to be implemented with the smallest number of edits. (Which is not at all the same thing as the shortest length, but does tend to correlate with length.)

ADDED: This is an example of what I'm talking about.