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.
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.
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.
Thomas A. Knight
Author of The Time Weaver
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.
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.
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
That is not a peer-reviewed article is it?
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.
=======
Science -- Sealed, Delivered.
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.
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 he can firm up into research hypotheses he can then try to validate through other means. Thus, the distinction between hypothesis-generating and hypothesis-validating activities.
Your point about his already having a solid background in SE is well taken. In fact, his experience may be exactly why he used Ask Slashdot: he's been around enough to know he doesn't know everything.
Good software design papers don't try to compare software development with civil engineering because (from reading the article):
People who do construction live in a very slow moving world.
The list goes on, and is actually rather obvious in many cases. One thing that architects and software developers have in common though: If the customer writing the requirements is an idiot, or worse an idiot who is dead set that they know better than you, then you can rest assured you will never deliver a satisfactory product.
If you're looking for great software design principles, start with the greats: Liskov, Fowler, Martin. Go to Object Mentor's published articles, 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 say that good architecture and design primarily revolves around managing dependencies correctly around your functional requirements and points of future extension, no matter what language you're in.
These concepts are going to become ever more important as we have to scale across more cores and more machines using functional languages like Erlang and Scala and techniques like map/reduce (see Hadoop, for Java).
but have you considered the following argument: shut up.