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."
Modularity (Score:3, Funny)
Re:Modularity (Score:5, Funny)
Re: (Score:2, Interesting)
Re:Modularity (Score:5, Funny)
Hilarious (Score:3, Interesting)
If you're looking for great software design principles, start with the greats: Liskov, Fowler, Martin. Go to Object Mentor's published articles [objectmentor.com], click on "Design Principles", and start reading.
These handful of articles changed the way I look at software, particularly OO software, but not necessarily restricted to OO, and highlighted the importance of controlling dependencies. All of the Gang of Four design patterns use one or more of the principles laid out in these white papers. I would go so far as to
Re: (Score:3, Interesting)
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.
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.
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: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: (Score:3, Informative)
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: (Score:3, Informative)
I know someone who had far worse numerical statistics than I did (as in a whole point lower GPA and around 150 points lower on the GRE) and somehow got into a better Ph. D. program (we're both going for PhDs in CS). He said that his professors told him a good deal of getting into a good Ph. D. program (perhaps this doesn't apply to just getting into one at all) was name-recognition of his recommenders, and he went to a large university with lots of recognizable faculty, while I went to a small one with only
Re:Modularity (Score:4, Interesting)
Re: (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 g
Abstraction and Frameworks (Score:3, Informative)
Abstracting code as much as appropriate allows you to reuse a significant portion of your code base. And with designing a framework for your applications that utilize that abstracted functionality to allow for a modular design of the actual business logic will greatly improve almost all projects.
The business layer should have no idea what the database is or how it works.
The presentatio
Code Complete (Score:3, Informative)
http://www.cc2e.com/
AC
Only Hire Women? (Score:5, Funny)
Personally I only do extreme, object oriented programming in COBOL, so I have nothing new to offer.
Re:Only Hire Women? (Score:4, Informative)
I realize you're joking but.....
http://www.wiley.com/legacy/compbooks/catalog/12974-7.htm [wiley.com]
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.)
Well what is my percentage? (Score:3, Insightful)
Re: (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:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Re: (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 thi
Re:Well what is my percentage? (Score:4, Insightful)
I suggest you stop using the services of anyone accreditted with such a degree.
Re: (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
Don't forget your .bib file (Score:5, Funny)
@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",
}
Re: (Score:3, Funny)
I was also wondering what possible value the information he got from this site could be in what should be a well-referenced work.
Ever see Let It Ride? This guy obviously has already a long list of development philosophies and methodologies.
Every time an item on the list comes up in this thread, you cross it out.
Whatever is left, there's your answer.
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:4, Informative)
Given the researcher's CV includes teaching software engineering at Boston University for several years, and being a project lead for Lotus for many years before that, I imagine he does already have many ideas and sources already. However, I imagine Ask Slashdot could provide at least two useful things for a PhD: direct data on what the "popular view amongst the technically-minded" is about what makes software better, and a wide and easily-cast net for picking up any links or texts that are in use that he might not be aware of.
His PhD seems to be a late-career attempt to crack the big philosophical nut, rather than an early-twentysomething scratching around for an idea. So this Ask Slashdot question seems to be an attempt to search every corner for data, however unlikely, rather than a lazy lack of effort.
Re: (Score:3, Interesting)
Given the researcher's CV includes teaching software engineering at Boston University for several years, and being a project lead for Lotus for many years before that, I imagine he does already have many ideas and sources already. However, I imagine Ask Slashdot could provide at least two useful things for a PhD: direct data on what the "popular view amongst the technically-minded" is about what makes software better, and a wide and easily-cast net for picking up any links or texts that are in use that he might not be aware of. His PhD seems to be a late-career attempt to crack the big philosophical nut, rather than an early-twentysomething scratching around for an idea. So this Ask Slashdot question seems to be an attempt to search every corner for data, however unlikely, rather than a lazy lack of effort.
You sort-of made my point for me, yet implied I called the guy lazy. Not so.
My use of the term "hypothesis-generating activity" is not derogatory. In fact, I think his use of Ask Slashdot, while likely to have a low SNR, is an interesting non-scientific way to gauge what other SE-types are thinking.
As you say, he can gauge the "popular view amongst the technically minded." No one would ever cite a Slashdot discussion as scientific evidence for anything. However, he can mine the results for ideas that
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: (Score:2)
Re: (Score:2)
I predict a long and prosperous career in today's IT economy.
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.
Re: (Score:3, Insightful)
Sorry to see that you're so jaded. No idea why you were modded up as 'insightful'. More like troll.
a few things... (Score:4, Interesting)
It's also good practice to try and make all of your code non-reentrant [wikipedia.org] and threadsafe [wikipedia.org]. 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: (Score:2)
Process, Process, Process (Score:5, Insightful)
Re: (Score:3, Interesting)
But smart people are nicer IMO.
A process need to evolve and when you spend more time on defining the process than solving the problem, you're in trouble.
I read somewhere, that a project is defined by a work on a problem which has not been solved previously.
Re:Process, Process, Process (Score:4, Interesting)
Process is important, but there are some common mistakes that can happen in organizations focused on process.
One mistake is thinking that a heavy process is a better process. For the 1000-person team working on a DoD project, a heavy process is necessary, but a 4-person team building a system that is not mission critical will just be slowed down and demotivated by a heavy process. Much of the ideas of agile development are about replacing heavy process elements with lighter ones (not throwing process out of the window, as some people seem to think).
Another common mistake is thinking that the details don't matter. For example, a code review can be very useful, if used in the right way. To get useful comments, you need reviewers who have experience with the language, the problem domain, the application etc. The coder must be willing and have time allocated to make changes based on the review comments. Preferably, before the code review, the code has already been run through a static analysis tool and the violations have been fixed, so the human reviewers can focus on the nontrivial problems in the code. To summarize, just having "code review" as part of your process manual does very little to improve the quality of the code, but a well executed code review is very useful.
Another easy trap is to have a detailed process manual, which describes a process different from the one actually used. To avoid this, you have to ensure that the developers are familiar with the written process, but you also have to change the written process when it turns out it is suboptimal in practice.
Always remember that the perfect process does not exist. It all depends on the context: some processes work well for experienced programmers but not for inexperienced, some processes work well for simple code bases but not for complex, small teams vs big teams, mature vs experimental code, team in one location vs distributed development, fixed deadline vs release when it's done etc.
Finally, know the limits of process. Even with a great process, you cannot get good code from bad programmers or get the code done before an impossibly tight deadline.
weak (Score:2, Insightful)
do your own damn homework.
Love,
the management
Yourdon (Score:3, Informative)
How to Design Programs (Score:3, Informative)
Object Thinking (Score:2)
The best answer I can provide you dear sir (Score:4, Funny)
Trust (Score:3, Interesting)
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: (Score:2)
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"
Forget Emacs... (Score:3, Funny)
Good software (Score:5, Insightful)
Good software has:
Re: (Score:2, Interesting)
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 (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.
Re: (Score:2)
Seems to me "Good Software" is simply software that addresses the problem it was designed to address in as economical a way as possible.
All these other facets are different beings entirely. Scalability? That's part of the problem domain, has nothing to do with how good your software is.... If your app only scales to one user, and you have..... one user.... You have created "Good Software." Software that other people can read is a often considered "good", but
Re: (Score:3, Interesting)
Good software design papers don't try to compare software development with civil engineering because (from reading the article):
spend some time a t a large software company (Score:2)
Re: (Score:2)
The problem with theory is that theory is nice and clean and abstract, while practice is gritty and dirty and tangled. No theory of software design is going to account for the battle of the egos that goes on between teams who all think that other teams aren't doing half the job that they would be doing.
Then you start moving into budget and manpower issues, and the very real issue that deals with actual va
Re: (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,
It's Easy (Score:2)
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 (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: (Score:3, Informative)
Indeed, that one is hard.
An interesting starting point on that conversation might be Weinberg's classic The Psychology of Computer Programming.
I've only read the original edition, haven't had a chance to get my hands on the 25th Anniversary revision yet (yeah, it's been out for a decade... I've had other things to do, and unfortunately buying and reading that has been down low on the list of priorities)
Weinberg's stil
Advice from another Computer Science Phd Student (Score:2)
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 extreme
Re:Advice from another Computer Science Phd Studen (Score:4, Funny)
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.
Re: (Score:3, Funny)
Muhahahah
Documentation (Score:5, Informative)
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.
Off the top of my head... (Score:2)
* Expose details that client code does care about
* Consider building everything as event driven state machines
* For distributed processes, read http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf [microsoft.com]
* WRITE TESTS FIRST
* No, I really mean it. WRITE TESTS *BEFORE* YOU WRITE "REAL" CODE.
* 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 int
lots of GOTO statements (Score:2)
Re: (Score:2)
Now, variable names based on cartoon characters, I could see that.
Remind me not to go to Tufts (Score:2)
Well... (Score:2)
There, those are some design fundamentals that I think are important. As for the code, don't be afraid to comment. Someone, like
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.
Psychology (Score:2)
Modularity, high boundaries, and simple interfaces (Score:2)
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.
My Principles (Score:3, Interesting)
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.
Re:My Principles (Score:4, Informative)
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.
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.
Re: (Score:2)
Re:Value of a PhD from Tufts? (Score:4, Informative)
2) I am doing separate literature searches, in various ways. I also wanted to get input from practitioners in the field, since much good work in software engineering does not come from the academic community.
Chuck Connell
Re: (Score:3, Interesting)
Get some good journal papers and go from there. Please, please take 'articles' with a grain of salt, no matter where they come from, but particularly online articles and to a lesser extent 'proceedings' (I note Stafford lists her journal papers with her conference ones, and this can be problematic)
Just my 2cents.
Tardy question... (Score:3, Insightful)
2 things (Score:2)
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 on
Sorry buddy (Score:2)
For an extreme example, take a look at Lockheed (Score:2)
http://www.fastcompany.com/magazine/06/writestuff.html [fastcompany.com]
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 o
The most important... (Score:2)
...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 p
That concept may not exist (Score:2)
Open-Closed Principle (Score:2)
http://www.objectmentor.com/resources/articles/ocp.pdf
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,
-M
Good programming..... (Score:4, Insightful)
I've heard that the key to good programs is.......GOOD PROGRAMMERS
The Joel Test (Score:4, Interesting)
How about the KISS principle? (Score:2)
Keep it simple, stupid.
That along with some comments and a clear writing style to include readable indentation levels, consistency of style, reasonably descriptive variable names, data structure fields, or object member names...
And as much as you might try to write a "beautiful algorithm," some of the best ones are simpler, have less feature creep, and can be used along with other simplistic ones that will achieve the same results.
Depends on the softwares purpose - Design Patterns (Score:2, Informative)
Common for most (i don't know about "all") succesfull software products is the fact that they are implemented using one or more Software Design Patterns [wikipedia.org]. For instance you will find that Model-View-Controller (MVC) [wikipedia.org] is extremely widespread in administrative software and similar database-driven applications, while it is probably not really usable in many other types of software (like graphics editors
Start with the maths (Score:2)
Good software means lacking in bugs, maintainable, (Score:2)
xxxx:0100 NOP
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)
The real answer (Score:3, Funny)
First, if it's not invented here, then it's crap.
Second, I'm the only one I trust to write it correctly.
Third, I work alone, and I don't write comments - see number two.
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.
Re: (Score:2)
Re: (Score:3, Funny)
// Comments.