PhD Research On Software Design Principles? 541
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."
Simple. (Score:0, Insightful)
Well what is my percentage? (Score:3, Insightful)
Process, Process, Process (Score:5, Insightful)
weak (Score:2, Insightful)
do your own damn homework.
Love,
the management
my 2 cents (Score:5, Insightful)
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"
Good software (Score:5, Insightful)
Good software has:
There is no general design for good software (Score:5, Insightful)
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.
Re:Wow, I applaud your laziness. (Score:1, Insightful)
Re:Modularity (Score:5, Insightful)
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.
KISS (Score:4, Insightful)
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.
How about a practicum with LM Space Systems first? (Score:3, Insightful)
Other places to look for: Linux Kernel team. Donald Knuths Tex/Latex.
Or, believe it or not, Blizzard Entertainment. They actually are the only entertainment software company I know of with a proven track record of extremely high quality software compared to others in the field.
But any core team of non-trivial low-level open source software technology will do actually. Python core team, PHP core team, your favourite Linux IO crew, Apache, OpenLaszlo, KDE, Haxe, Blender,
Bottom line: Join some tight crew of people that build stuff everybody uses or many people rely on to work. Hang with them for a month or two, then you'll have a better idea how exactly to approach your topic.
Management (Score:3, Insightful)
Having an experienced architect is vital. Enforcement of the values of the team, especially with respect to interface specifications, is important.
Value of a PhD from Tufts? (Score:4, Insightful)
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.
Tardy question... (Score:3, Insightful)
Re:Well what is my percentage? (Score:2, Insightful)
Holy hell. Find your own damn 'links' (or Spaghedeity forbid, some other books/papers).
In all seriousness, good luck to you though.
PS. Get off my lawn.
Re:Well what is my percentage? (Score:4, Insightful)
I suggest you stop using the services of anyone accreditted with such a degree.
Re:Well what is my percentage? (Score:3, Insightful)
Perhaps he should spend his time interviewing acknowledged experts in the field or at least studying papers written by them. Hell, even interviewing students in his local CS department would be better than basing an argument on what some random Slashdot user posted.
Mostly, though, I'm appalled at the quality of post-secondary education that this guy has supposedly received (and paid for!) if he believes Ask Slashdot is a good way to conduct academic research for a PhD thesis. If I were him, I'd ask for a refund.
Re:Modularity (Score:5, Insightful)
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.
Re:Good software (Score:4, Insightful)
No, I'm not saying that. I should have worded that sentence as: A principal or group of principals who care about the future of the software and is active in its development
There must be some end user or group of users who will continue to drive the needs of a given piece of software and help it evolve.
Translation: (Score:1, Insightful)
I thought getting my PhD would make me uber 1337. Well, I finally got accepted into a PhD program, and now I find myself completely over my head. I don't even have a topic for my thesis!
Could someone do my homework for me? Also, could you supply your name, address and phone number? I'm going to need someone to go in and defend my dissertation for me. kthxbai.
Good programming..... (Score:4, Insightful)
I've heard that the key to good programs is.......GOOD PROGRAMMERS
Hmmm (Score:1, Insightful)
Re:Well what is my percentage? (Score:5, Insightful)
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.
Interfaces are very important (Score:3, Insightful)
It is difficult to make clean and powerful interfaces, however. You really have to understand the nature of the problem you're trying to solve in order to pick the most natural groups of functionality. Very often, if you're trying to get something done in a reasonable amount of time and don't need to maintain the code for that long (though beware--you'll find yourself using, a decade later, programs that you thought you'd rewrite "next month"), it's better to code something quick and specific.
The cleanliness of an interface basically boils down to how little information you can pass to it, and how little information you need from it, in order for it to do what you want; and to what extent all information and data goes through explicitly defined interface elements (e.g. an interface in Java). (Here I'm drawing a distinction between data, e.g. the content of a character stream, and information, which is "hey, there's a character stream here, go work on it".)
The power of an interface basically boils down to how many different high-level operations can be constructed from mixing and matching components of the interface. For example, compositing operations tend to be powerful (e.g. take A, take B of the same type, perform some operation to produce C of the same type from A and B).
There are lots of other generally useful strategies, but I find this one of the most overlooked, especially by otherwise really talented coders (who can tend to make interfaces more complex because they are talented enough to work with something that complicated).
What the Heck? (Score:4, Insightful)
Re:Well what is my percentage? (Score:5, Insightful)
Re:Well what is my percentage? (Score:1, Insightful)
Even for those who go to school, most practitioners jump straight into industry after getting their bachelor's. This means that the academic research done at most universities is at least partially disjoint from what's going on in the "real world" ("Ivory Tower syndrome", blah blah blah), and a wide assortment of "best practices" and "general patterns" don't make it into academic literature.
If one actually stops and considers the medium that he's asking the question in, which is rife with tech enthusiasts (many of us who also happen to be software engineers), one can easily see that it is a great place to get people talking and hear a lot of different ideas and concepts about how things are.
This is obviously not the best source for expert data, but it's a great way of brainstorming and perhaps networking with experts who can provide more concrete sources later. Anyone who can't see that should be appalled by the quality of their own education.
Re:Management (Score:5, Insightful)
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
Re:Well what is my percentage? (Score:5, Insightful)
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.
Re:Well what is my percentage? (Score:3, Insightful)
Sorry to see that you're so jaded. No idea why you were modded up as 'insightful'. More like troll.
Re:Value of a PhD from Tufts? (Score:1, Insightful)
Many departments are now offering direct-to-PhD programs from Bachelor's degrees, without having any required courses in Research Methods or anything close to what graduate academic life is actually like, and for some there's a major adjustment period involved.
If you don't have an advisor or someone familiar with the process helping you (and most departments don't exactly facilitate that process either), it can be quite a daunting task.
Say what you will about self-direction and "figure stuff out on your own"
Say what you will about the "quality that schools put out these days", but it looks like academic arrogance is something that has stuck around since your day as well.
Re:Well what is my percentage? (Score:5, Insightful)
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.
Re:spend some time a t a large software company (Score:3, Insightful)
It's been my experience that big software development companies almost invariably spend so much of their time worrying about those horrible real world conditions that it rarely occurs to them that those conditions didn't just happen by coincidence and that they could take steps to avoid the problems in the first place. Smaller shops tend to be much better at this.
Before anybody dives in and lectures me on scalability, let me say that IME the difference has a lot more to do with the kind of unprofessional, unproductive culture that can only thrive at mid-levels of large companies than anything to do with the scale of the project or the absolute size of the development team. Indeed, if you read the Bruce Webster article on a runaway project that was linked earlier today, it's pretty obvious that parts of the project code base were becoming unmanageably large because of incompetence and not because the project requirements actually necessitated that much code.
If you want to learn real world lessons, go watch a small- to medium-sized software shop, where there isn't space for the lazy and/or dictatorial idiots to hide, preferably one where everyone is a partner or there is some sort of profit-related pay so people have an incentive to really follow practices they think are helpful. Plenty of difficulties still arise in such environments, but they are much less likely to be own goals by the development team, and the team are much more likely to have effective ways to deal with them that would be of interest to others.
Re:Well what is my percentage? (Score:3, Insightful)
Re:Good software (Score:2, Insightful)
I disagree with the opening para of the link (Score:2, Insightful)
Re:Value of a PhD from Tufts? (Score:1, Insightful)
Sure, you cite the papers and the literature, but you talk to people to find out what papers and literature you should be looking at.
Again, Slashdot is probably all but useless - people are not. When I'm starting a new research problem, I ask myself - who would know about this. Then I go talk to that person. Saves a TON of trouble.
Re:Management (Score:4, Insightful)
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.
Re:Well what is my percentage? (Score:3, Insightful)
It's certainly not the only strategy to create or discover new ideas, but who knows when a post by J. Random Luser might contain that cool spark that sends you down a new path of thinking?
So if you don't want to participate, don't. If you want to lie to him and tell him something like "procedural code is on the ascendancy again", that's also funny. If you just want to post goatse links; well, this is Slashdot, and nobody's stopping you from that either. But you shouldn't necessarily discount the value of what he might be gaining from this little exercise. It could provide insight into the leading edge of future software design.
Re:Modularity (Score:3, Insightful)
He's asking the wrong question the wrong way for the level of work he should be doing. Probably because he's got "book" experience, and not 10 years of work experience. That said, you won't find many people teaching at university that would do any good answering his questions either. They may be good at their jobs, but not at multiple project managements... the ones that are really good don't teach.
I think that shows the problems with computer degrees in general. They don't really teach long-term project management in university (it's beneath them). They want to teach you lots of great theory, but just expect you to learn how to USE it thru osmosis. Something like a PhD for software engineering really shouldn't be offered to anybody with less than 5-7 years working at programming and managing programmers.
Made with love (Score:3, Insightful)
Most bad software is rushed, created by bored programmers, in a corporate decision to create another boring and faulty-by-design software system.
Most good software is written by a small team of very excited developers who love what they do, are given the resources to do so, and who couldn't even think of a more exciting system to build.
You can add all the modularity or simplicity or readability or whatever you need, but unless it is made with love, it won't be beautiful.