Software Architecture References?

[neocpp]

Do you guys have any recommendations for books which teach how to design software at a high level?

I'm okay at the mechanics of coding, but I've noticed that I make a lot of mistakes when designing a system, especially one where the requirements constantly evolve (research code). I do learn from it -- and have been getting better over time -- but it typically gets so bad that after a certain point I have to throw in the towel and do a complete rewrite. I can't imagine that this is common, although maybe I'm wrong.

I don't think my current method is feasible with larger systems than what I've been working with, so I was wondering if you had any recommendations on how to deal with design. Any books or other references would be welcome. My background is in mechanical engineering and it's hard for me to separate the wheat from the chaff.

 

[Ken g6]

I've had this book recommended to me. I bought it, but really haven't gotten into it. Maybe because it doesn't appeal to me, maybe because I rarely read any programming books these days, I'm not sure.

http://www.amazon.com/Head-First-Design-Patterns-Freeman/dp/0596007124/

What language are you using for your "research code"? That might make a difference. If you're using C, it's hard to structure your program nicely beyond simply having lots of functions. And I have no idea what can be done with Fortran.

It sound like you may be suffering from a lot of feature creep, which can sometimes lead to rewrites making sense.

 

[Merad]

Honestly the only reliable way I've found to learn to design better software is to write software and learn from your mistakes. An alternative would be to find someone who has good experience and work with them. The problem with the latter of course being, how do you know that someone is good at designing software?

Frankly this is a big problem in the programming world, IMO. Most software is terribly designed or just a few degrees away from terrible. I'm not sure if we just don't yet have solid generalized guidelines for structuring software, or if we aren't being effective at sharing that information.

Design patterns are definitely good to know, but many of them don't deal as much with high level structure, rather, they're a template to solve a particular problem.

Edit: By the way, we used the book Ken linked in school. It almost seems like it was written for middle or high school kids, which can be annoying, but it does cover a lot of design patterns and has effective explanations.

 

[purbeast0]

one major problem that i've experienced multiple times that leads to piss poor design is when clients just keep tacking on "one off" features. like so many specific cases and stuff that are "special" cases, then they need a new one, then another. and then it just turns to crap.

 

[clamum]

I've seen a lot of pretty crappy designed software in my career as well as have been the source of some crappy software.

In my experience, the crappy design was usually because "get this fucking thing done, NOW. I need it yesterday" was the marching orders. Now, you can't use that as an excuse all the time, but there have been a lot of times where it just wasn't feasible to sketch out a perfectly designed, quality piece of software. There simply WAS NOT time to do it. From my experience, again, clients wanted to see something. If it was more-or-less riddled with bugs, that was manageable, because at least they could see *something*.

 

[Markbnj]

There are two of these, both editions I believe are available as online HTML and epubs...

http://aosabook.org/en/index.html

Having read one and most of the second I'll say two things: first, there are a lot of great insights into the design and construction of popular applications like bash and audacity. Second, I think you can probably read both of them cover to cover and not come away with any better sense of what the common patterns of software architecture are, or what language is used to describe them. That in itself is insightful, but may not be answering the question you were asking.

 

[neocpp]

Thanks for the recommendations. I've seen and used some design patterns before but it probably would be helpful to have a reference for it. I don't have the GoF book either so maybe I should pick that up as well. I'll also take a look at the books linked about the design of open source software, it seems like it would make an interesting read even if I end up not knowing how to apply it to my own code.

Honestly it seems like part of the problem is just the nature of the work (developing new finite-element based methods), which is inherently going to be messy since we don't know ahead of time what will work, or how well it will work. I don't really have clients in the usual sense, but my advisor does essentially want one-off features month after month. It doesn't help that he doesn't seem to mind too much about the code quality (I understand his position; his goals are to get the science out as quickly as possible), but it just makes things unmanageable for me after a while. I know there are still better ways to go about it than what I have been doing, but it makes me feel slightly better that this is not unexpected.

Ken g6, I know you asked which language was being used. I am currently using C because that is what I am most familiar with. It's getting time for a rewrite though. Do you have a recommendation for another language? I considered using C++ at the beginning but decided it wasn't necessary (and I am a bit weaker with it). However, I probably will end up using it for this next version. The ease of automatic differentiation alone is enough to convince me to use it over C, but perhaps there is a better choice.

 

[Ken g6]

developing new finite-element based methods

Partial Differential Equations are a little over my head.

I did see mention of a language called Julia in this thread about Matlab and Octave. Looks like Julia is based partially in C, and can call C, but has a lot more capabilities.

 

[neocpp]

Partial Differential Equations are a little over my head.

I did see mention of a language called Julia in this thread about Matlab and Octave. Looks like Julia is based partially in C, and can call C, but has a lot more capabilities.

I have actually used Julia before, and it does seem pretty good. It has also apparently matured quite a bit since the last time I saw it (the documentation in particular seems much better now).

The main reason I have stuck with C/C++ is mostly familiarity with that set of languages and the fact that there are already tons of libraries written with official bindings for C/C++, but it looks like Julia has an easy interface that I didn't know about. The only minor annoyance I ran into from before was the 1-based indexing, which I'm sure it makes it easier for people who want a matlab replacement.

 

[Cogman]

I have actually used Julia before, and it does seem pretty good. It has also apparently matured quite a bit since the last time I saw it (the documentation in particular seems much better now).

The main reason I have stuck with C/C++ is mostly familiarity with that set of languages and the fact that there are already tons of libraries written with official bindings for C/C++, but it looks like Julia has an easy interface that I didn't know about. The only minor annoyance I ran into from before was the 1-based indexing, which I'm sure it makes it easier for people who want a matlab replacement.

C++ isn't a bad choice for scientific computing, but it allows a lot of evils. I would suggest looking up modern C++ coding principles. Using shared/unique pointers, auto everywhere, etc. C++ as a language evolved significantly with C++11. Also as a side, you may want to look into using user defined literals. For scientific computing those are pretty helpful to make sure you don't make any cm/km sorts of mistakes.

Python is also a good choice to look into. It has a lot of libraries in the form of SciPy that may do 90% of what you are looking for.

And of course Julia is always an option.

 

[neocpp]

C++ isn't a bad choice for scientific computing, but it allows a lot of evils. I would suggest looking up modern C++ coding principles. Using shared/unique pointers, auto everywhere, etc. C++ as a language evolved significantly with C++11. Also as a side, you may want to look into using user defined literals. For scientific computing those are pretty helpful to make sure you don't make any cm/km sorts of mistakes.

Python is also a good choice to look into. It has a lot of libraries in the form of SciPy that may do 90% of what you are looking for.

And of course Julia is always an option.

Thanks! I have gotten back into C++ recently (last version I really used was c++03) and have been learning/using the c++11 features mentioned, but I hadn't seen user defined literals before. Seems pretty useful like you said for keeping units consistent.

The first few versions of the code we wrote were in pure Python, but it actually turned out to be too slow for anything except as a proof-of-concept. It seemed like if we were going to write a significant portion using the C interface to python we might as well do all of the numerics directly in C anyways (we still use python for visualization and other post-processing). I'm not a python expert though, so maybe it could have been sped up. The benchmarks I've seen for Julia seem to indicate that speed is not an issue for it (usually within a few percent of C).

 

[Cogman]

Thanks! I have gotten back into C++ recently (last version I really used was c++03) and have been learning/using the c++11 features mentioned, but I hadn't seen user defined literals before. Seems pretty useful like you said for keeping units consistent.

The first few versions of the code we wrote were in pure Python, but it actually turned out to be too slow for anything except as a proof-of-concept. It seemed like if we were going to write a significant portion using the C interface to python we might as well do all of the numerics directly in C anyways (we still use python for visualization and other post-processing). I'm not a python expert though, so maybe it could have been sped up. The benchmarks I've seen for Julia seem to indicate that speed is not an issue for it (usually within a few percent of C).

np. I'm really excited about the direction C++ is evolving towards. Herb and Bjornn are really doing a good job at evolving the language and cleaning up a lot of the badness of it.

Another language that may be interesting, though I would suggest anything mission critical be developed in it, is Rust. The language itself is really quite interesting C/C++ level performance and memory safety without a garbage collector. The language is quite well designed, but it doesn't have anywhere near the adoption of C++ or even Julia to my knowledge. It is more of a "if you like playing with new programming languages" sort of language