Slashdot Mirror
PhD Research On Software Design Principles?
cconnell writes "I am working on a PhD in software engineering at Tufts University. My interest are the general principles of good software design, and I am looking for links/references on this topic. The question is: What design/architecture qualities are shared by all good software? Good software means lacking in bugs, maintainable, modifiable, scalable, etc... Please don't tell me 'use object oriented methods' or 'try extreme programming.' These answers are too narrow, since there is good software written in COBOL, and by 1000-person teams for DoD projects. I am looking for general design principles. If it helps, I am trying to build on the ideas in this article from some years back."
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.
Good code avoids putting variables or functions unnecessarily in the global namespace. This means that the likelihood of name collisions is less likely so your code project is more likely to play nice with other code projects.
It's also good practice to try and make all of your code non-reentrant and threadsafe. As processors sprout an increasing number of cores, it is important to make sure your code can take advantage of the extra power.
It's also a good idea to COMMENT your code and DOCUMENT your processes. There's nothing worse than stumbling across something you wrote 10 years ago and having no idea how it works.
From one of the most respected developer/managers in the business, The Joel Test is a checklist that may help you with your ideas. http://www.joelonsoftware.com/articles/fog0000000043.html
Process are nice and needed ...
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.
I love the smell of lithium in the morning
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.