Slashdot Mirror
PhD Research On Software Design Principles?
cconnell writes "I am working on a PhD in software engineering at Tufts University. My interest are the general principles of good software design, and I am looking for links/references on this topic. The question is: What design/architecture qualities are shared by all good software? Good software means lacking in bugs, maintainable, modifiable, scalable, etc... Please don't tell me 'use object oriented methods' or 'try extreme programming.' These answers are too narrow, since there is good software written in COBOL, and by 1000-person teams for DoD projects. I am looking for general design principles. If it helps, I am trying to build on the ideas in this article from some years back."
This is an excellent place to start:
http://www.cc2e.com/
AC
A software project is only as good its documentation. Look at successful open source projects -- many of these have excellent project documentation that tells you all about the architecture, structure, features, coding practices, standards implemented, data formats, data validation information and so forth.
WHat kills so many projects is a lack of good documentation -- if no one can figure out how to pick up the ball and code a feature or a bugfix or whatever, then the code will wither. This applies even to closed source projects -- one of the things that screwed Vista over, for instance is that much legacy code was in need of rewrite -- except there no one new what the code did anymore.
My blog
I realize you're joking but.....
http://www.wiley.com/legacy/compbooks/catalog/12974-7.htm
Not that I recommend it unless you also enjoy root canals. (Sorry about the link, I couldn't find a better one on short notice.)
God, schmod. I want my monkey man!
1) I do have a starting point. See the article I linked to in my OP.
2) I am doing separate literature searches, in various ways. I also wanted to get input from practitioners in the field, since much good work in software engineering does not come from the academic community.
Chuck Connell
a) What you're trying to do is extremely complex (i.e. physics simulation code)
b) It needs to be highly optimized, which often comes at the expense of readability
c) The language itself is not highly readable in the first place (assembly is inherently difficult to read, while C# reads almost like English)
I find myself writing much more verbose comments whenever I tackle somewhat complex problems. Comments are not only useful in describing "how", they're important in describing "why". Code simply can't inform a reader why a particular algorithm was used in place of another. It can't describe various things to look out for the next person to modify the code which you yourself may have run into. And, it can't give nice high-level overviews of expected usage patterns. These are most crucial in your most complex code.
It's absolutely impossible to avoid complexity at some level when you're trying to produce complex results. Perhaps it's the case where comments are largely unnecessary based on the language and type of code you're producing, but a lack of comments would be a real hindrance in the environment I work in.
Irony: Agile development has too much intertia to be abandoned now.
Given the researcher's CV includes teaching software engineering at Boston University for several years, and being a project lead for Lotus for many years before that, I imagine he does already have many ideas and sources already. However, I imagine Ask Slashdot could provide at least two useful things for a PhD: direct data on what the "popular view amongst the technically-minded" is about what makes software better, and a wide and easily-cast net for picking up any links or texts that are in use that he might not be aware of.
His PhD seems to be a late-career attempt to crack the big philosophical nut, rather than an early-twentysomething scratching around for an idea. So this Ask Slashdot question seems to be an attempt to search every corner for data, however unlikely, rather than a lazy lack of effort.