Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PhD Research On Software Design Principles?

kdawson posted more than 6 years ago | from the and-don't-tell-me-to-use-emacs dept.

Education 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."

Sorry! There are no comments related to the filter you selected.

Modularity (2, Funny)

Reverend528 (585549) | more than 6 years ago | (#23829097)

The sell any one piece knows about the other pieces, the better off the system will be.

Re:Modularity (5, Funny)

Anonymous Coward | more than 6 years ago | (#23829119)

The rom anyone posts, the srow it gets.

Re:Modularity (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23829447)

I argee. Fucntonial decompostoin hepls in delvepoeemnt scaling, but uou need a genious to design an archiertecture and ungerstand what "it as a whole" should do.

Re:Modularity (0)

Anonymous Coward | more than 6 years ago | (#23829479)

the more anyone spots, the worse it stag.

Re:Modularity (3, Interesting)

zolf13 (941799) | more than 6 years ago | (#23829123)

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.

Re:Modularity (4, Insightful)

SatanicPuppy (611928) | more than 6 years ago | (#23829345)

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.

Management (2, Insightful)

mollog (841386) | more than 6 years ago | (#23829437)

The maturity of the management and its ability to insulate the coders from the noise from corporate is important to good code development.

Having an experienced architect is vital. Enforcement of the values of the team, especially with respect to interface specifications, is important.

Know your stuff (0)

Anonymous Coward | more than 6 years ago | (#23829155)

Make sure the programmers know the application they are writing. I have seen programmers that wrote apparently competent code but it didn't do what it was supposed to because they didn't know what they were supposed to be accomplishing with the code. If the coders can't perform the task with pencil and paper (I know, how old school) then they can't possibly do it with code. This is from an accountant that has had a "home" computer since Bill Gates did tech support.

Re:Modularity (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23829553)

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.

Re:Modularity (1)

FR-lopet (628130) | more than 6 years ago | (#23829569)

Modularity and keep it simple !

Complex problems can be generally splitted in several simpler problems, easier to solve independtly.
Then the trick is to bind everything elegantly and ... to keep it simple as well.

Most programs written can be summarized by: a structure/class which contains an array of struct/class which contains an array/struct ...

Another tip: if you can enumerate, half your problems are solved.

About bugs: every software contain bugs. Even a perfect software at a given time will become buggy in the future (2k year bug anybody ?).
That's why softwares must be maintained. Fire & forget solutions is part of the problem ...

Simple. (0, Insightful)

Anonymous Coward | more than 6 years ago | (#23829137)

Download the latest OpenBSD [] source code and read up. It's well written, well maintained and very well documented.

Code Complete (3, Informative)

Anonymous Coward | more than 6 years ago | (#23829145)

This is an excellent place to start:


Only Hire Women? (4, Funny)

Shadow Wrought (586631) | more than 6 years ago | (#23829151)

That's what Slashdot told me yesterday.

Personally I only do extreme, object oriented programming in COBOL, so I have nothing new to offer.

Re:Only Hire Women? (3, Informative)

SirLurksAlot (1169039) | more than 6 years ago | (#23829353)

I realize you're joking but..... []

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.)

Simple is beautiful (1)

GerardAtJob (1245980) | more than 6 years ago | (#23829153)

Simple is beautiful :)

Well what is my percentage? (3, Insightful)

140Mandak262Jamuna (970587) | more than 6 years ago | (#23829157)

I mean what percentage of your PhD will be mine? Is it your PhD or our PhD. You want the degree, son? Earn it.

Re:Well what is my percentage? (0)

Anonymous Coward | more than 6 years ago | (#23829261)

Exactly my thought too.

Perhaps the person posing the question should start here: []

Re:Well what is my percentage? (2, Insightful)

rd1101 (1306033) | more than 6 years ago | (#23829481)

Seriously. Is this what constitutes 'research' today? Undergrads copy from Wikipedia, and graduate students ask Slashdot?

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? (3, Insightful)

Sir_Real (179104) | more than 6 years ago | (#23829491)

What? So... you can't ask for help in getting your PhD? My my... There are QUITE a large number of doctors out there that are apparently sharing their degrees with colleagues, friends, family, and... strangers on the internet....

I suggest you stop using the services of anyone accreditted with such a degree.

Re:Well what is my percentage? (2, Insightful)

eln (21727) | more than 6 years ago | (#23829519)

I was sort of thinking this, but I was also wondering what possible value the information he got from this site could be in what should be a well-referenced work. Writing a thesis and backing it up with quotes from random people on the Internet doesn't seem like the wisest decision.

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:Well what is my percentage? (1)

hcmtnbiker (925661) | more than 6 years ago | (#23829529)

I think that you would agree that if he researches this question everyone who he pulls answers from doesn't really 'own' part of his PhD. Otherwise the only way he could 'earn' it would be to pull answers out of his ass instead of figuring out what really where the best.

Re:Well what is my percentage? (1)

Opportunist (166417) | more than 6 years ago | (#23829545)

Hey, he's doing the right thing in today's economy world: Try to use every resource available to you, preferably free, crib and claim it's yours.

I predict a long and prosperous career in today's IT economy.

Re:Well what is my percentage? (0)

Anonymous Coward | more than 6 years ago | (#23829549)

I mean what percentage of your PhD will be mine? Is it your PhD or our PhD. You want the degree, son? Earn it.
The original poster needs some help with what makes good Phd research, not what good software design principles are...

Re:Well what is my percentage? (1)

fgaliegue (1137441) | more than 6 years ago | (#23829613)

Well, just think of it this way: the author is looking for advice. Maybe you think you're the Man Of The Day(tm) when it comes to software design, but then maybe you're talking absolute rubbish.

Such a thread is interesting to the author just as a melting pot of ideas from which he can pick... Well... Whatever he thinks fits his theory.

See, you may well output a thousand line summary of what you think is great, he will only, maybe, pick some tens of it. But:

* the synthesis of it won't be yours, it will be his;
* be sure that any valuable contributions _will_ be credited to the original author (who knows, this may be you).

I don't quite understand the "insightful" moderation, honestly.

code one line (0)

Anonymous Coward | more than 6 years ago | (#23829165)

then have a shot of whiskey

if you still can read that line, code another one.

Objectmentor (0)

Anonymous Coward | more than 6 years ago | (#23829171)

Seems to be a good starting point for Design principles.

Maybe this could help (1)

cephah (1244770) | more than 6 years ago | (#23829175)

Last semester we had software architecture and design and we used Software Architecture in Practice [] as reference. I found it pretty good and I'm sure it'll hold lots of information relevant to PhD students, too.

a few things... (4, Interesting)

sneakyimp (1161443) | more than 6 years ago | (#23829183)

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.

Re:a few things... (0)

Anonymous Coward | more than 6 years ago | (#23829351)

Yes there is... Stumbling across something you wrote 10 years ago and finding it somehow doesn't work when you're pretty sure you left it in working condition

Re:a few things... (1, Informative)

Anonymous Coward | more than 6 years ago | (#23829391)

I think you mean make your code reentrant. Reentrant is a positive property. Non-reentrancy is a negative property.

Re:a few things... (0)

Anonymous Coward | more than 6 years ago | (#23829411)

There's nothing worse than stumbling across something you wrote 10 years ago and having no idea how it works.
Stumbling across something your idiot ex-coworker-who-is-now-your-boss wrote 10 months ago could be worse - well, worse for the "no yelling obscenities over the cube walls" policy at least. (I hate that #@!&^% policy)

Wow, I applaud your laziness. (0)

Anonymous Coward | more than 6 years ago | (#23829185)

You could always read a text book on Software Engineering.

Re:Wow, I applaud your laziness. (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23829309)

You could always read a text book on Software Engineering.
Let me guess-- you've probably also read a textbook on Software Engineering, and complained that the author never bothered to research the experience of people outside Acadamia, thereby limiting the book's usefulness?

Re:Wow, I applaud your laziness. (1)

Intron (870560) | more than 6 years ago | (#23829423)

Or, you know, consult experts on formal software development practices [] rather than random slashdot readers.

Process, Process, Process (5, Insightful)

CastrTroy (595695) | more than 6 years ago | (#23829187)

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.

Re:Process, Process, Process (0)

Anonymous Coward | more than 6 years ago | (#23829585)

"Having a documented process that you follow to ensure that code is free of bugs" ... written by someone who has never tested software.

I would love to see your 'bug free' software.

People and the computers made by people are flawed. It's inherent in the system.
No amount of documentation will change that.
Shifting deadlines may improve the quality, but even then, it will not be perfect.

Flawless code is the pipedream of blue pill poppers.

weak (2, Insightful)

Anonymous Coward | more than 6 years ago | (#23829197)

Dear Mister PhD,
do your own damn homework.

the management

Yourdon (2, Informative)

davebarnes (158106) | more than 6 years ago | (#23829205)

Read books by Ed Yourdon written in the 1970s.

Keep it simple ... (0)

Anonymous Coward | more than 6 years ago | (#23829209)

Found this article

from this search

Have fun ...

How to Design Programs (2, Informative)

ramakant (256472) | more than 6 years ago | (#23829213)

Object Thinking (1)

warrior (15708) | more than 6 years ago | (#23829217)

I'd recommend the book Object Thinking [] . The methods can be applied to any programming language. I'd also recommend that anyone working on the project have a strong background in computer science and experience to go with it.

The best answer I can provide you dear sir (4, Funny)

Anonymous Coward | more than 6 years ago | (#23829219)

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.

Solve specific problems and avoid "frameworks" (1)

blippo (158203) | more than 6 years ago | (#23829221)

Solve specific problems, and avoid generic "frameworks."

Reduce configurability, dare to code business/core logic.

Know your domain; If a problem seems complicated, the solution tends to be complicated.
(And if you know nothing, all problems seems complicated.)

Iterate. Refine.

Trust (2, Interesting)

ELProphet (909179) | more than 6 years ago | (#23829225)

The article from earlier today seems to tell you how not to do it.

From my experience, I think the biggest thing is trust. The managers need to trust the developers to do what's right, and listen to the developers when they make suggestions on how to do it better. The developers need to trust that the managers won't get in their way, but will keep them on track and keep them insulated from distractions. Developers need to trust each other, that everyone's code works well etc, and trusts each other enough to ask for help when they need it. Once everyone trusts everyone else and can work well together, the project will be more successful.

Little secret: this goes for any project.

Re:Trust (1)

CastrTroy (595695) | more than 6 years ago | (#23829463)

If you work with people you can trust, you will probably end up with a good project. However, that trust (or lack thereof) doesn't come from nowhere. If you have coworkers that you don't trust, then it probably has a lot to do with experiences that they have put you through, which have ended up in less than satisfactory results. Developers that turn in ugly/buggy code, managers that are constantly changing requirements, or trying to add an every increasing number of features, these are the things that can make you not trust your coworkers. I've worked with many people that I don't trust. But apart from firing them (doesn't usually work with managers), or changing jobs, there's a very limited number of things you can do about this.

my 2 cents (4, Insightful)

trybywrench (584843) | more than 6 years ago | (#23829227)

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"

Forget Emacs... (2, Funny)

jesdynf (42915) | more than 6 years ago | (#23829233)

I'm happy I don't have to tell him to use "Ask Slashdot".

Most universally useful (0)

Anonymous Coward | more than 6 years ago | (#23829235)

// Comments.

Good software (4, Insightful)

kevin_conaway (585204) | more than 6 years ago | (#23829239)

Good software has:

  1. Continuous integration
  2. A large and useful suite of tests that are run during #1
  3. A paying customer who cares about the future of the software and is active in its development
  4. A manager who understands the full software development life cycle
  5. Developers who understand the business domain and problem the software is designed to solve

Re:Good software (2, Interesting)

seeker_1us (1203072) | more than 6 years ago | (#23829459)

# A paying customer who cares about the future of the software and is active in its development # A manager who understands the full software development life cycle

So you are saying that open source software that isn't written for a paying customer is not good?

I think there's a lot of stuff on sourceforge that would contradict that.

The manager thing, I can go with, if you broaden the definition of manager to include things like what Linus does with the Linux kernel.

Re:Good software (3, Insightful)

kevin_conaway (585204) | more than 6 years ago | (#23829563)

So you are saying that open source software that isn't written for a paying customer is not good?

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.

spend some time a t a large software company (1)

peter303 (12292) | more than 6 years ago | (#23829243)

I laugh at these eggheads who dont know real world conditions.

Re:spend some time a t a large software company (1)

no.unames.left (1011807) | more than 6 years ago | (#23829493)

Why the assumption there is a natural and inherent link between 'people who do' and 'people who know'? Do 'real world conditions' provide the opportunities for reflexivity, assessment, and critical engagement with practices?

That kind of information (0)

Anonymous Coward | more than 6 years ago | (#23829247)

could get you shot

John McCain's Baby Mama +1, Informative (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23829249)

is a crack whore.

Furthermore, there are a number of frightening facts about John McCain that I absolutely must make public. But before I do I need to go into a fair about of detail explaining how I, hardheaded cynic that I am, trust McCain about as far as I can throw him. Hang in there; this explanation won't take long. Please note that many of the conclusions I'm about to draw are based on cogent and virtually incontrovertible evidence provided by a set of people who have suffered immensely on account of McCain.

Though the impudent spring up like grass and amateurish agitators flourish, they are doomed to be destroyed forever -- especially if we name and shame McCain's subalterns for their effrontive acts of absenteeism. In particular, if McCain were to use more accessible language then a larger number of people would be able to understand what he's saying. The downside for McCain, of course, is that a larger number of people would also understand that he likes to quote all of the saccharine, sticky moralisms about "human rights" and the evils of militarism. But as soon as we stop paying attention, McCain invariably instructs his trained seals to go to great lengths to conceal his true aims and mislead the public. Then, when someone notices, the pattern repeats from the beginning. Though this game may seem perverse beyond belief to any sane individual it makes perfect sense in light of McCain's cankered belief systems.

McCain occasionally shows what appears to be warmth, joy, love, or compassion. You should realize, however, that these positive expressions are more feigned than experienced and invariably serve an ulterior motive, such as to create a kind of psychic pain at the very root of the modern mind. His accomplices are tools. Like a hammer or an axe, they are not inherently evil or destructive. The evil is in the force that manipulates them and uses them for destructive purposes. That evil is John McCain, who wants nothing less than to court a malignant minority of frowzy miscreants.

The salient point here is that the worst kinds of directionless wheeler-dealers I've ever seen often take earthworms or similar small animals and impale them on a pin to enjoy watching them twist and writhe as they slowly die. Similarly, McCain enjoys watching respectable people twist and writhe whenever he threatens to dominate the whole earth and take possession of all its riches. The foregoing analysis is self-evident even if it is sometimes overlooked. Less evident are the specific ways in which we should arraign him at the tribunal of public opinion. Separatism is irrelevant here. What are the lessons for us in this? First, it's that he leaves me no choice but to swallow whatever he dishes out. And second, I once tried to explain to him that his declamations will encumber the religious idea with too many things of a purely earthly nature and thus bring religion into a totally unnecessary conflict with science. Rather than feel ashamed of himself, McCain got angry at me. What this says is that when some malign, crotchety vermin first introduced me to McCain's ethically bankrupt memoranda, I felt that civilization had reached a nadir of bleakness. Nevertheless, I can state with absolute certainty that McCain is out to twist the history, sociology, and anthropology disseminated by our mass media and in our children's textbooks. And when we play his game, we become accomplices.

Mutual efforts against jaded hedonism are not just an educational process designed to teach people that we must try our level best to fight for our freedom of speech. These efforts also serve as a beacon, warning the world of the pudibund consequences of McCain's obtuse ventures. If you think that this is humorous or exaggerated, you're wrong.

As the oft-repeated saying goes, "Many of us do not wish to live within McCain's walls of irrationalism". The importance of that saying is that it reminds us that one of McCain's favorite tricks is to create a problem and then to offer the solution. Naturally, it's always his solutions that grant him the freedom to accelerate our descent into the cesspool of autism, never the original problem. Even with no further evidence than what I've previously presented I would feel -- and no person on Earth can alter my opinion -- that wherever you look, you'll see McCain enforcing intolerance in the name of tolerance. You'll see him suppressing freedom in the name of freedom. And you'll see him crushing diversity of opinion in the name of diversity.

Let me mention again that McCain's litanies are based on two fundamental errors. They assume that what I call ugly pillocks are more deserving of honor than our nation's war heroes and they promote the mistaken idea that skin color means more than skill and gender is more impressive than genius. McCain does not desire to benefit humanity but rather to demonstrate an outright hostility to law enforcement. You have my word that the failure of his disciples to recognize that his violations of the rules of decency are so reckless they beggar belief casts doubts upon their methods, period. While some of his intimations are very attractive on the surface and are undoubtedly entertaining, they ultimately serve to introduce absurd, baseless, terror-ridden lawsuits intended to destroy the lives of countless innocent people. By comparing today to even ten years ago and projecting the course we're on, I'd say we're in for an even more hostile, wrongheaded, and nutty society, all thanks to McCain's prevarications.

I don't know when credentialism became chic, but McCain has mastered the art of bamboozling unwary listeners by introducing names of persons and events of which they have only a hazy recollection and then making statements, seemingly documented, with such authoritative confidence that they never think of trying to clarify their own recollections or consulting a reference work. An equal but opposite observation is that to believe that McCain values our perspectives is to deceive ourselves. At this point, all I can do is repeat a line from my previous letter: "The documentation of this matter is abundant and conclusive". Just like dirty clothes on the floor and cluttered closets, McCain's mess won't go away if we simply look the other way. If a cogent, logical argument entered McCain's brain, no doubt a concussion would result. Simply put, I, for one, am fully in accord with those who say that it is incumbent upon all of us to confront McCain's statements head-on. And here, I think, lies a clue to the intellectual vacuum so gapingly apparent in McCain's magic-bullet explanations.

It is painful to write such truisms, but we must invigorate the effort to reach solutions by increasing the scope of the inquiry rather than by narrowing or abandoning it. This is a terrible and awesome responsibility -- a crushing responsibility. However, if we stick together we can can show the world that this is a free country, and I insist we ought to keep it that way. And if you think that bad things "just happen" (i.e., they're not caused by McCain himself), then you aren't thinking very clearly. Given his record of shady dealings, we can say that McCain has -- not once, but several times -- been able to distort and trivialize the debate surrounding onanism without anyone stopping him. How long can that go on? As long as his shabby, vainglorious ideals are kept on life support. That's why we have to pull the plug on them and oppose our human vices wherever they may be found -- arrogance, hatred, jealousy, unfaithfulness, avarice, and so on.

McCain gets a lot of perks from the system. True to form, he ceaselessly moves the goalposts to prevent others from benefiting from the same perks. This suggests that despite McCain's protestations and rhetoric, the facts do not support his claims. But you knew that already. So let me add that conceited, bloody-minded thought police would be far more bearable if they didn't make us less united, less moral, less sensitive, less engaged, and more perversely benighted. I put that observation into this letter just to let you see that just because he and his loyalists don't like being labelled as "salacious lunatics" or "namby-pamby election-year also-rans" doesn't mean the shoe doesn't fit. Let me end by saying that I know that what I have written in this letter will send many readers (especially any who are big fans of John McCain) into a tizzy or a tantrum. I am sorry, but I remind them that the abysmal unholy-types who collaborate with McCain should be spat upon -- or worse -- for their lack of integrity.

Kilgore Trout

It's Easy (1)

kmsigel (306018) | more than 6 years ago | (#23829255)

Write code that doesn't have bugs. Make sure it is as simple as possible, and no simpler.

Seriously, isn't this kind of thinking what *you* are supposed to be doing for this thesis?

There is no general design for good software (4, Insightful)

this great guy (922511) | more than 6 years ago | (#23829293)

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.

Advice from another Computer Science Phd Student (1)

thermian (1267986) | more than 6 years ago | (#23829301)

You need three things

1: A bottle of your favorite alcoholic beverage.
2: Three seasons of Southpark.
3: Make that two bottles, and some snacks
4: An internet connection.
5: ...

Um, I forget where I was going with this, which pretty much sums up my first year. Ah, I have such fond memories of trying to find papers when I was starting. Now I'm writing up I can look down upon you first year phd noobs and laugh, oh yes, perhaps even 'heartily'.

Well anyway, there's always google scholar. Worked for me, its an extremely useful tool.

Re:Advice from another Computer Science Phd Studen (3, Funny)

Opportunist (166417) | more than 6 years ago | (#23829595)

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.

Time (1)

locallyunscene (1000523) | more than 6 years ago | (#23829311)

When you say "good design" do you consider efficiency to be a part of that? I work for one of those "1000 person teams" and what I have noticed is that processes(CMMI level 4) keep the schedule and quality on track. That's not really news since that's what a 1000 case studies have said before. However, I would not want to take all of that baggage to a 10 person team that needs to remain agile to compete in their market.

IMO, designing with scalability in mind always helps, but I have no evidence beyond anecdotal to back this up.

Patterns, anti-patterns (0)

Anonymous Coward | more than 6 years ago | (#23829313)

There are a number of nice books on software design patterns and anti-patterns. See
and etc. The pattern I love to contemplate the most is "big ball of mud" aka "spaghetti code".

Documentation (5, Informative)

morgan_greywolf (835522) | more than 6 years ago | (#23829315)

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.

always "age" your work (0)

Anonymous Coward | more than 6 years ago | (#23829317)

When you finish something, hide it until the deadline. This is because if you ever give your boss something before the deadline, he will pull some nonsense out of his rear that he thinks he needs added to the project.

Plus whatever your shortest turnaround time is, that is what he will expect in the future, no matter how complex the task.

In general, try deceive and ignore your boss as much as possible.

Quint-2 model for software product quality (1)

mAx7 (137563) | more than 6 years ago | (#23829323)

The QUINT-2 model (extended from ISO 9126) is a model to discuss various aspects of software product quality, see:

Check the Quint-2 browser if you like a nice visual representation:

Hope this helps. Don't hesitate if you have additional questions.

Off the top of my head... (1)

wurp (51446) | more than 6 years ago | (#23829325)

* Hide details that client code doesn't care about
* Expose details that client code does care about
* Consider building everything as event driven state machines
* For distributed processes, read []
* Design for the known specifications, only design to support expected spec changes if you're sure those particular spec changes will happen
* Break down the system into units cohesive within themselves, but not cohesive with other units. (Duh)

That's it, off the top of my head.

default deny (0)

Anonymous Coward | more than 6 years ago | (#23829329)

default deny (whitelist not blacklist)

lots of GOTO statements (1)

circletimessquare (444983) | more than 6 years ago | (#23829341)

no documentation, and variable names based on the names of the programmer's girlfriends

Re:lots of GOTO statements (0)

Anonymous Coward | more than 6 years ago | (#23829451)

and variable names based on the names of the programmer's girlfriends

So *that's* why so many variables are called leftHand and rightHand!

Re:lots of GOTO statements (1)

Opportunist (166417) | more than 6 years ago | (#23829637)

Umm... what girlfriends?

Now, variable names based on cartoon characters, I could see that.

Remind me not to go to Tufts (1)

antifoidulus (807088) | more than 6 years ago | (#23829347)

seriously, your PhD thesis is THIS broad? And you have to go to slashdot even to get started on it? I feel bad for you....

Well... (1)

KGIII (973947) | more than 6 years ago | (#23829361)

Options should be where they belong. Configuration/installation should offer as many options as are needed and then more. (Since when is an "advanced installation" really just one or two options?) Remember that not all of us use a mouse all the time so keep keyboard navigation easily available. Read some of the UseIT articles. Keep the layout consistent throughout the application.

There, those are some design fundamentals that I think are important. As for the code, don't be afraid to comment. Someone, like me, might come along after you and be pretty much inept without the comments so try to be clear.

KISS (3, Insightful)

Todd Knarr (15451) | more than 6 years ago | (#23829363)

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.

Psychology (1)

Tablizer (95088) | more than 6 years ago | (#23829369)

After years of debating on usenet and wiki, I've concluded that software engineering is largely a psychological process if one is looking beyond just performance issues. Due to Turing Complete principle, there are many many solutions to any given problem (same output). The solution that people prefer seems to be the one that best fits the way they think or the way they think about the domain (problem-space). The problem is that until we can dissect an entire working brain, psychology varies per person and is a "soft science".

Those who claim they have objective evidence of the Golden Paradigm/Technique are probably full of squishy brown stuff.

Umm.. (0)

Anonymous Coward | more than 6 years ago | (#23829383)

Do your own homework.

Fix on don'ts, better than dos (0)

Anonymous Coward | more than 6 years ago | (#23829401)

Don't allow the executive accountant to tell how the software will work as you won't allow the executive accountant to tell where the ceiling in the hose will go.
Don't allow the PHB to tell how long it'll take to develop as you won't allow the PHB to tell how long it will be to build the bridg.
Don't allow the beancounter to decide on the developers' profiles as you won't allow the beancounters to decide that a mason can take the architect's role.

Finally don't allow the company to decide to get in in projects where it's obvious the company lacks the maturity, the workforce and the professional profiles to take the deal as you won't allow a company to build an airport with two masons and a plimply young engineer.

Ok, ok, let's return to real world: current software is just OK. People wanting to pay for it clearly shows it. The paper you cite obviates reality: "if a house were like too many software projects, people wouldn't dare to go into". Well, but they *do* dare to "go into" the software and pay good bucks for it, so who cares?

Modularity, high boundaries, and simple interfaces (1)

BytePusher (209961) | more than 6 years ago | (#23829403)

I've personally written one medium size project(around 100k). As the project scaled I found there were a few things that really made a difference. Modularity with high boundaries and simple interfaces between modules. What I mean by this is that as a program grows more complex if you reduce the number of dependencies maintainability increases greatly. Also, if it's possible to use the standard data types(i.e. deque instead of MyReallyCoolIntegerDeque) for communication between modules it's much easier to maintain compatibility between modules. Also, one thing I can never seem to get across to developers is to write readable code. This means naming functions according to their function and not as some cryptic acronym. It means naming variables what they are, even if their name has to be a sentence(Though, usually a simple and obvious name can be found if you think hard enough.)

How about a practicum with LM Space Systems first? (2, Insightful)

Qbertino (265505) | more than 6 years ago | (#23829433)

I strongly suggest you see if you can get a few weeks of academic internship with these [] people. Also know as 'Those who write the right stuff [] . They actually do know how to write software.

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, ... whatever. And while people will start bickering that Apache or Blender code is oh so crappy in this or that area, rest asured that all projects of that kind, *incuding* the aforementioned *all* have core team members who are very well aware of the downsides of their software. And thus can help you out in your pursuit for details on professional software developement, because they also know the pitfalls.

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.

My Principles (2, Interesting)

Synchis (191050) | more than 6 years ago | (#23829435)

I've been programming for almost 15 years and have spent alot of that time very gradually refining my own design principles. Here are my basics:

1. Modular designs. Modular code is generally more maintainable and more scalable.
2. Self-documenting code. If you read my code, you can understand whats going on just by the code. There are very few comments, because very few are needed.
3. Occam's Razor: The simplest solution is often the best/most correct solution. Over-complicating things often leads to maintainability issues later on.

I am currently working on a project that requires me to share code with several other people. None of them have needed much direction when picking up my code and re-using it because I've used sound design principles when writing it.
There really is no single answer that handles all situations. I use some more specific principles when doing different types of projects, depending on whether I'm doing Database design, web development, stand-alone applications or complex application systems.
System design is very subjective, every person seems to have a different way of doing things. One thing I always ask myself is this: Will I be able to work with this code 6 months from now? If the answer is no... then I have work to do to improve the design.

Value of a PhD from Tufts? (3, Insightful)

microTodd (240390) | more than 6 years ago | (#23829441)

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.

Re:Value of a PhD from Tufts? (1)

going_the_2Rpi_way (818355) | more than 6 years ago | (#23829579)

Agreed. Get thee to a library my friend. If you can't cite the 10 most important and 10 most recent journal articles on the question, what the hell are you doing asking for help on Slashdot? Who's your supervisor?

Tardy question... (2, Insightful)

glgraca (105308) | more than 6 years ago | (#23829449)

In some countries you have to submit a project in order to enroll into a doctorate programme, in others you become part of an ongoing project and your work will be a spinoff from that. Either way, I can't see how you are already working on your PhD and still making these sorts of questions.

Sorry but I must rant ! (1)

iXiXi (659985) | more than 6 years ago | (#23829461)

How can you do PhD work on software design principles if you haven't delved into all forms of programming for yourself and applied them to real world scenarios? Please don't tell me you are an academic writing some paper to then stay school-side and claim you are an expert. You should get a job, assuming you don't have one already, in the corporate jungle like the rest of us and do the research for yourself. A /. doctor, is this a first? How do you put that in your thesis and defend it? If you are an industry expert soliciting opinion only, then more power to you.

2 things (1)

Maxo-Texas (864189) | more than 6 years ago | (#23829475)

1) Affordable.

2) Good foundation.


1) is where most software and management people both fail.
managers refuse inexpensive updates to keep the software robust because there is "No R.O.I." until they then buy or have written a new "wonder package" at much higher expense than the deferred maintenance.
Meanwhile developers (and users) design systems that are nice but so expensive they really can't be done.

2) Software, unlike buildings, is constantly changing- and usually it is equivalent to adding new floors onto buildings more than adding new wings. This means as you add more and more floors, the foundation must be made stronger. This work is rarely allowed (see #1) so when you write software, you need the experience to say, "I can inexpensively make this foundation strong enough to handle 3 new floors of upgrades and triple the expected load... however i can see that making it handle 5 times the load is so expensive the project won't happen.


So you have such basics as
Reasonably normalized data.
Abstraction layers so that you can replace a layer without breaking anything.
Fields big enough to hold at least 3 digits more than you ever expect to happen in reality.
Foundation library classes that are well-defined, obviously reusable- and not too many of them (maybe 80-100 max - more than that and people start rewriting them because they can't find them).

the worst bit is that now managers think
1) programmers can maintain skill without actually working on code
2) programmers are generic resources and that a college grad or indian resource can step right in at full productivity.
3) languages and platforms will not expire within 3-4 years because the old mainframe programs never did (but they do today-- they are all so interdependent on each other).

You're going to need more than that... (0)

Anonymous Coward | more than 6 years ago | (#23829477)

I hope you have more of a frame work to build your thesis on. Have you read many PhD dissertations? They are usually centered around in-depth research on a very specific problem. You are describing getting some general design principles that might make a great book on the subject, but not a thesis.

C.f. "Good building techniques" with "Primary cause of premature failure of self sealing stem bolts in extra-solar habitation facilities". See the difference?

Sorry buddy (1)

flowerp (512865) | more than 6 years ago | (#23829483)

Slashdot won't be doing the PhD work for you.

Books to Read: (1)

Doctor-R (885000) | more than 6 years ago | (#23829503)

Read: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition by Frederick P. Brooks

Literate Programming by Donald E. Knuth

Beautiful Code: Leading Programmers Explain How They Think by Andy Oram and Greg Wilson

But the real answer is: since there is no professional testing / licensing for software engineers or software managers; most of them are actually incompetent and/or inexperienced.

Good Projects? (1)

Kevin72594 (1301889) | more than 6 years ago | (#23829535)

I don't have an answer to your question, but it might be helpful if we could get some examples of projects people think embody the idea of "good software." Then discuss principles these projects used which made them "good software."

Anonymous Coward (0)

Anonymous Coward | more than 6 years ago | (#23829591)

"My interest are the general principles of good software design, and I am looking for links/references on this topic."

FAIL. You might squeak by on a masters thesis with that kind of topic. Maybe.

Translation: (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23829599)

Dear Slashdot,

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 software, (0)

Anonymous Coward | more than 6 years ago | (#23829601)

I find that good software is usually grown. It is not about specifying everything upfront and building it. But also good software doesn't always mean popular or user-friendly. It is simply modular and has easily replaceable pieces that communicate with more(mostly) or less well defined interfaces. This to alleviate the growing pains when the software evolves. Plan9 comes to mind or Unix shell utilities.

For an extreme example, take a look at Lockheed (1)

merreborn (853723) | more than 6 years ago | (#23829605)

Specifically, the group that wrote the software for the space shuttle. With a defects-per-line rate less than 1/1000th of the average, they're doing something right. []

Of course, with a full pages of documentation for every 10 lines of code, and an average daily output of roughly a dozen lines of code, their process is much more time consuming and expensive than can be supported by most development budgets.

But they serve as an example of the wide spectrum of approaches to software development.

Read Code Complete (1)

bleuchez (1298201) | more than 6 years ago | (#23829609)

I've been reading Code Complete by Steve McConnell at home and he really hits the nail on the head on how do design and write good software.

He now has a second [] version of his book out, I highly recommend it as a study on good software.

Litmus Test (0)

Anonymous Coward | more than 6 years ago | (#23829621)

In my experience, the best litmus test for good software design is if the application, when finished, can accomplish useful tasks that were never in the original requirements. I've seen numerous such occurrences.

For example, a month after deployment, a customer has called and said, "I need a report for X". Then, I've responded with something like, "Go to this report, filter on this field, and sort by that field". In this manner, one can accomplish some specific task without making a single change to the application. And, it's not just limited to reports. I've seen various non-report examples as well.

If written well, the application has a built-in X factor that anticipates future needs.

How about a reasonable schedule? (1)

jimbertling (1309387) | more than 6 years ago | (#23829631)

Not that a reasonable schedule always results in good software, but an unreasonable one always seems to result in bad software.

The most important... (1)

Chysn (898420) | more than 6 years ago | (#23829635)

...thing about the study of software design is good analogies. Without good analogies, your thesis won't make any sense at all.

Compare software development to carpentry, automotive repair, civil engineering, cooking, music composition, sex, stamp collecting, spelunking, bird-watching... software developers can't understand treatises on software development unless there's metaphor involved.

And mix it up a bit. If you use carpentry in a paragraph about class modeling, make sure to use automobiles in a paragraph about unit testing.

Or, if you find mixed metaphor lacks grace, just stick with cars.

You might want to clarify your ideas w/ analogues (0)

Anonymous Coward | more than 6 years ago | (#23829641)

If you consider good software to the clear, effective, and durable communication of heuristics then one might look to other aspects of the human condition where this has become necessary or brought forth fruit. Law? Math? Economics? The Art of War? If you can identify the over-arching ideas that seem to lead to good heuristics, how they're expressed in software should become more obvious, and then you can work on devising some system of quantifiying the meaningful attributes.

That concept may not exist (1)

unity100 (970058) | more than 6 years ago | (#23829643)

since everything related to design and implementation are generally defined by the datelines and budget that is available. you may have to define what the context for 'good' is.

Open-Closed Principle (1)

betelgeuse68 (230611) | more than 6 years ago | (#23829649)

You want princples, the Open-Closed Principle would be a big one:

Too bad 95% of the code bases out there suck a**. Which is why I don't do software development anymore. I'll stop there.

Sytems Admin/Integrator,

"Writing Solid Code" (0)

Anonymous Coward | more than 6 years ago | (#23829653)

..published by the Microsoft Press.

I kid you not.

Good programming..... (3, Insightful)

lpcustom (579886) | more than 6 years ago | (#23829665)

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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?