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."
Code Complete (Score:3, Informative)
http://www.cc2e.com/
AC
Yourdon (Score:3, Informative)
How to Design Programs (Score:3, Informative)
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.
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.)
Re:a few things... (Score:1, Informative)
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
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 or a spreadsheet app).
But I would say that "Uses an established Design Pattern" is one aspect you need to include.
Another aspect might be the method in which the actual programming is planned and controlled during implementation. A documented and proved method for the implementation, such as Unified Process (UP) [wikipedia.org] or similar, may be something you could consider adding to your answer.
- Jesper
P.S. Please forgive me for adding Wiki-links. Having a PhD in Computer Science I am sure none of this is new to you. They are mostly provided for other readers
Re:a few things... (Score:1, Informative)
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 presentation layer should have no idea what the business layer is doing or how it works.
We really pushed these principals on a project I worked on a few years ago. We had a reporting system that had to access 3 different databases, 2 3rd-party systems, and interface with business rules over 4 different departments and employees/sales in 3 different states. We created a custom data access layer that handled all of the data-related functionality for us. So in the business layer code, we never had to care about the data source, we had objects that represented the data in memory that all inherited from the same base data object/collection. Each specific report or functionality was based on one of 4 specialized frameworks that handled Crystal Reports, Office automation, work flow, and HTML generation. Each of the frameworks was based off of an even more basic type that handled the underlying multi-threading and work flow of the process. And all of that functionality was designed to be abstracted from the user interface so that we could build a Windows based interface to start with, and as the 3rd party apps gained more flexibility we could directly call our application's business logic and work flow from the other applications.
Anyway, one of the first projects I look at when stepping into a new project or job is to get the abstraction and design cleaned up. There is no sense beating on business logic when the underlying technology is going to cause you more headaches and piss off your users. And once you get that technology straightened out, you can focus on business logic and get the users a product that not only meets their needs, but also meets your needs in support and maintenance requirements.
-Rick
Why is everybody hating on the OP? (Score:2, Informative)
Now, if Slashdot is his ONLY source, it's a different story. But I find that rather unlikely. This seems like a pretty good shot in the dark that might yield some interesting leads that he can research further.
Maybe it's just me, but exploring a wide variety of sources seems like GOOD research rather than poor.
Re:Modularity (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 a few. Apparently, it reflects well on you if you worked with someone famous, even if all you did was sweep the floors of the lab.
To this day, that system still sickens me, but I probably would have been spared much grief if I had known that when I applied. Perhaps it would be useful information to you. You may also want to try contacting faculty directly with your research topics and seeing if you could work with them if you get in prior to submitting your application. The faculty make up the committee that reviews your application, so having someone on it that really wants to work with you is probably a good idea.
A Ph. D is a lot of hard work and involves a lot of nonsense, however, and you can honestly gain about the same degree of skill as an average Ph. D. program will impart with about three months of research. Consider whether you really need to subject yourself to one.
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.
Re:There is no general design for good software (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 still alive, and blogging, and apparantly writing novels these days too. He's probably a very good source for information on how our humanity can help or hinder our ability to design and write and test good software.
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:Management (Score:3, Informative)
In these kinds of situations, the person defining the requirements and communicating with all departments is likely going to be the programming side supervisor. The same person who is also likely responsible for scheduling, performance reviews, technical comment in departmental meetings, and is likely in their position as a result of being promoted from a programmer position after 5+ years. This person, while likely very skilled, is also likely the key contact for any number of legacy systems, and is probably so busy that developing a test plan is not even on their radar.
In these small development shops, you are not likely going to be hired on as a 'coder'. You are going to be hired on as a 'developer'. You'll have high ownership of the project from start to finish, meaning you may get specs handed to you, but you will likely have direct contact with the users, and you will be responsible for architecture, design, interfaces, testing, deployment, documentation, and training.
Once you get into a slightly larger IT department, and you have 4+ developers, you'll start to see more specialization and distinction. At 4+ underlings, the supervisor is going to be leaving their technical work behind and focusing almost explicitly on management and communication. But I have yet to see a company under 500 employees run more than 3 developers (with the exception of consultants brought in for very specific jobs). And once you get over 1000 employees, you are more likely to have a CIO to get IT a seat at the grown-up table and an independant process improvement unit that fullfills some of the problem spotting that IT would perform in smaller organizations.
-Rick
That's a lot of criticism, so for the record.... (Score:2, Informative)
- I am not conducting an opinion poll. I asked for links/references to known work.
- I am asking "the software development community" for input because software engineering is different from some other disciplines. It is unlikely a physics researcher would get new ideas about gravity from a public discussion forum. But there is a lot of good work about software engineering that does not come from the academic world, and is not published in academic journals. Some is not in printed format at all.
- If someone tells me an original idea, or a new take on an old idea, I will cite them in my paper.
- Asking people for ideas is not "getting someone else to do my homework for me". Anyone who thinks that it is has never done anything difficult.
Chuck Connell