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."
The rom anyone posts, the srow it gets.
I agree. Functional decomposition helps in developement scaling, but you need a genious to design an architecture and understand what "it as a whole" should do.
This is an excellent place to start:
http://www.cc2e.com/
AC
Personally I only do extreme, object oriented programming in COBOL, so I have nothing new to offer.
If brevity is the soul of wit, then how does one explain Twitter?
I mean what percentage of your PhD will be mine? Is it your PhD or our PhD. You want the degree, son? Earn it.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Good code avoids putting variables or functions unnecessarily in the global namespace. This means that the likelihood of name collisions is less likely so your code project is more likely to play nice with other code projects.
It's also good practice to try and make all of your code non-reentrant and threadsafe. As processors sprout an increasing number of cores, it is important to make sure your code can take advantage of the extra power.
It's also a good idea to COMMENT your code and DOCUMENT your processes. There's nothing worse than stumbling across something you wrote 10 years ago and having no idea how it works.
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.
Use object oriented methods or, in the alternative, try extreme programming. Refactor whenever possible. Dissect and redistribute. Make sure the team is cohesive and factionalized. Compensate for all scalable factors on a frequent basis, using randomization approaches. Never, and this is not set in stone, allow the project to objectify to the point of opacity. This cannot be overemphasized: you can never add too much manpower to software tasks.
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.
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
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.
Most good software I've seen follows the KISS principle internally: Keep It Simple, Stupid. Pieces of it know what they're supposed to do and they do just that. They don't mix in functionality for several things. They don't have embedded knowledge of how they relate to the rest of the system. They've got clean, modular interfaces that let you test just that one part to make sure it's doing what it should and not doing what it shouldn't, without having to haul in large parts of the rest of the system. They either don't make assumptions about what the rest of the system will hand them or they've got those assumptions clearly documented in the interface and they test that their input conforms to those assumptions and produce a clear error if it doesn't. Eventually some pieces will have to embody the design and logic, understand how all the individual pieces fit together to make the system work, but that's their job: to orchestrate the work being done, not to actually do it.
Another indicator is that good software is designed with the certainty that it will change, that it will be extended and altered over time. Good software has that assumption built in. Bad software, by comparison, is often flagged by statements like "Don't worry, we're never going to change that." or "We don't need to worry about doing that.". Software designed not to change or be extended is either bad software or rapidly becomes bad software once it hits production.
And no, nothing particularly new there. It's been this way for about 50 years.
I'm intrigued by this question, because I would assume that by the time you've reached this level (i.e. have a Master's in CS or something related) you would already have an idea as a starting point. Furthermore, I thought that the first part of any PhD-level research was an intensive Literature Review.
So, in other words, you should search LexisNexis, EBSCO, etc., and find some journal articles that talk about this. Read some books like Gang of Four or Mythical Man Month. Lastly, do your own data gathering. Find a bunch of Post-Mortems and start to put your own patterns together.
Oh, wait, all that would require work.
Seriously...I teach college-level courses and have multiple graduate degrees...and I'm continuously amazed at the quality that schools put out nowadays.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
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.
2: Three seasons of Southpark.
That's The Simpsons for coding. Southpark is for debugging.
Man, you obviously have no idea. One of the critical skills is to choose the right tools for the right job.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Sit down because what I'm about to say is very profound and could make you tear up.
I've heard that the key to good programs is.......GOOD PROGRAMMERS
Beer! It's what's for breakfast!
From one of the most respected developer/managers in the business, The Joel Test is a checklist that may help you with your ideas. http://www.joelonsoftware.com/articles/fog0000000043.html
Just be sure to add your Slashdot research to your .bib file:
@MISC{Slashdot:2008,
AUTHOR = "Level 70 Opinionated Geeks",
TITLE = "Musings on Software Design Principles",
HOWPUBLISHED = "Randomly Moderated Posts",
MONTH = "June",
YEAR = "2008",
NOTE = "Results from Ask Slashdot when I was too lethargic to look up CS articles online",
}
Why would a PhD student solicit for information on a social website? Shouldn't you be doing the research yourself??
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
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.
Wow. This is the first time I've seen endian compatibility problems in web browsers.
I agree with what you're saying but would put a more pessimistic slant on it. A programmer shouldn't take a personal, face-to-face, cube-to-cube interest in what goes on in other departments hoping to make improvements on business processes. A programmer should do that because otherwise the specs will be wrong, the design will be flawed, and the tests will be lacking.
You will be told, "There are people whose job it is to talk to all the stakeholders, understand their disparate needs, and assemble the requirements." This is correct. There are also people whose job it is to design the system, other people who are supposed to implement parts of the system, and other people who are supposed to test the system. Odds are that many of these jobs will be assigned to incompetent, clueless, and/or underworked people. Odds are that even the competent people will miss things that might cripple the design later. It improves your odds immensely if you do some reconnaissance work on your own.
Don't duplicate the work done by others (unless you figure out that a particular person is useless.) If somebody talked to the manager in group X, then you should talk to the second in charge. If someone talked to a supervisor, talk to the grunts. Read their requirements first, then go casually chat with them as if the requirements were correct. Observe their looks of panic and horror. Then start taking notes. Requirements are often collected manager-to-manager and leave out vast swaths of essential functionality.
After you feel good about the requirements, review the test plan. If anything is obviously missing, mention it. If anything looks suspiciously underspecified, chat innocently with the testers about it. "I bet testing internationalization is gonna be a bitch. How the hell do you even type right-to-left text in Windows, anyway?"
This is your job as a coder -- to have the backs of the people you work with and save them from themselves. If you're lucky, someone is doing the same thing for you. The guy who wrote the test plan might look at your issue tracker to see what features you plan on implementing. Maybe you missed something. The guy who wrote the high-level specs might look over your design docs to see if you've made any obvious mistakes with respect to deployment requirements.
A lot of people see this kind of behavior as being absolutely contrary to fundamental engineering principles. On the contrary; it is sound human engineering. It shouldn't even be a political problem. The only people who won't appreciate the feedback and correction are the ones who are consistently shown to be incompetent.