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."
From what I can see, the real answer, process. Having a documented process that you follow to ensure that code is free of bugs, and that code is readable. How you accomplish those things isn't exactly important. For making sure code is readable and maintainable, you can have formalized code walkthroughs, or you could just have another coder read it over before it is accepted into the project. Ensuring that the software doesn't have any bugs is another issue. You should have a repeatable test environment, whether it be unit tests, or even just a list of actions peformed by an actual person, in order to check that everything is working correctly. Some approaches work better than others. But the real important thing in the end, is to have a defined process, and ensure that it is being followed.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
In my experience the single most important part to a software project is good requirement gathering and analysis. As for development, every program that i know uses some concept of divide and conquer. Breaking up a large problem in to a set of connected smaller problems simplifies writing good code. It's easier to write small bug-free modules then it is to write a large program all at once.
It would be interesting to find the cutoff point where a problem should be further divided and when it is discreet enough. Also, it would be interesting to know when a developer begins to introduce bugs or less optimized code. Like after x many lines or like y many hours.
It would be interesting to try and quantify code elegance. I forget who said it but there's a saying "code that looks good is good"
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Good software has:
Good software is written by good people. There is no general rules you can follow to automagically make your software good.
Sure some rules will tend to make your software a little bit better: KISS design principle, release early release often, unit tests, etc. But fundamentally it's all about people.
Then you might ask "what makes a good developer good". Well's that's not so easy to answer.
You can also end up with weird, inefficient code, because the specs are poorly written and no one is allowed to have enough oversight to realize it.
That's more of a management problem, I suppose, but I've all too often seen "glue" methods that were expanded beyond their scope due to the fact that the designers of Method A and Method C were never allowed to meet, and the people who came up with glue Method B were forced to all sorts of unholy kludge make them work with each other.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
You're a PhD student and you don't know this?
And you apparently don't know how to find it?
Hint: google for "Software Engineering graduate" to find grad classes in software engineering. Read their reading list. If that's too much effort, just read Parnas and Boehm to start.
It makes me sad that I can't get into a PhD program, with thesis topics already lined up to go, and you have apparently never taken a Software Engineering grad class.
How is polling the opinions of a diverse group of people with expertise in the field not "research"?
Sure, if he uses your ideas you will get referenced. Reading the ideas of others is an extremely important part of what research is. Just because I used Maxwell's equations in my PhD thesis, doesn't mean that it's his work and not mine. I cited the sources, and was entirely honest about which bits were mine and which were from somebody else. Then, in a seperate section, I discussed the importance of my contributions.
The work of others typically contributes the majority of the volume (and some of the value) of any PhD thesis or research paper.
"It is better to die for an idea that will live than to live for an idea that will die" - Steve Biko
Excuse me, how do you find links? Asking people who are most likely to know seems a perfectly natural way to do research. Get off your high horses people. He didn't ask you to spoon feed it to him, he just asked for pointers. Obviously you have nothing to offer so why did you bother to post! I've never seen so many asshats in my life complaining about how he does his research.
Why bother
I would disagree about insulating coders from the "noise from corporate" in many situations.
If you are doing development for a small organization say, 1-500 employees, you as a programmer, are not likely to have a whole lot of insight into the business rules of some department on the other side of the building. Playing opperator for specs having management relaying messages from the accountant isn't going to help your situation.
IT has a great place as a strategic process improvement center for most companies. Everyone uses IT resources now. Accounting, shipping, sales, collections, lease/loan departments, etc... You, as a programmer, have a chance to see into the life of every department in your organization. You have the oppertunity to see process inefficiencies and recommend improvements. People as a whole, like the path of least resistance. If Jim in sales is used to entering his deals into the company's sales system, then Jill from Accounting prints out the sales report and types it into the accounting software, and finally Sally gets a copy of the bill and packages up the order in the ware house where she enters the information into the inventory system... All of these people will keep doing the exact same dual entry because that's the way they are used to doing it. But being in IT and getting to see these processes, you can see the obvious problems, the likelihood of error, and the wasted time.
But you need to get out of the IT cave and get into action with the other departments.
On the other hand, if you like coding and hate people, you can always get into a code ware house where an absurd number of programmers do naught but code off of specs with no input, no chance to design, no chance to see the larger picture...
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
This isn't necessarily his/her intention. The OP could just be looking for some general ideas to get going (or to rule out bad ones before proceeding). I see this as a hypothesis-generating activity, not one in which he/she'd expect to get hypothesis-validating information.
Oh, FFS. Whenever you're doing any serious research, talking to your colleagues -- and yes, damn it, when you're doing software engineering, a lot of /.ers are your colleagues -- is how you form good ideas and organize your thoughts. This is true in any field. I've noticed that a lot of hotshot geeks like to imagine themselves as Lone Geniuses Bringing Great Ideas Into The World Through Sheer Brilliance And Force Of Will. Guess what? The LGBGIITWTSBAFOW approach works reasonably well for small software projects and one-off research papers. For anything bigger, such as a PhD thesis, it's a recipe for failure. Every computational tool you use in your daily work started through collaborative research.
The submitter is clearly not asking anyone to write his thesis for him. He's gathering ideas, that's all. If you have something useful to contribute, speak up. The fact that you choose to snipe at him instead ("I'm appalled at the quality of post-secondary education that this guy has supposedly received") pretty clearly indicates that you have neither the experience to understand what he's doing nor the expertise to contribute to or comment on his work.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.