I'm an undergraduate student who studies software architecture as a "researcher apprentice" as we would name around here.
My question is pretty much explained on the title. Often, as a young researcher I hear that for software engineering in general industry is way different than the start of the art. Sometimes, people mention that "we" as researchers add way too much stuff that are not really used in the industry. Sometimes due to the lack of time, or budget some documentation might go out. You can tell that by the tons of diagrams, and loads of sheets of paper we do while at an undergraduate course at computer science.
So, seeing that this book is related to advices from experts specially at industry, as I saw at some comments at Amazon about the book, what would you (the author) think about this? Are they related or not? And how much?
I've also seen on the book glossary that there is some discussion about patterns which is also a focus of my research study. How do you see patterns being applied at industry?
Answering in my capacity as editor of 97 Things Every Programmer Should Know, contributor to 97 Things Every Software Architect Should Know, and co-author of POSA4: A Pattern Language for Distributed Computing and POSA5: On Patterns and Pattern Languages:
The 97 Things Every Software Architect Should Know book is very much about current state of the practice and working what is known as opposed to innovative directions for the future.
Research must necessarily focus on things that are not being done, otherwise it will only encourage stasis and the status quo.
Research must also necessarily focus on things that are being, otherwise we will miss opportunities for understanding why thing work and how we can improve them based on accumulated rather than hearsay or forgotten knowledge.
I have a strong interest in patterns, particularly in connection with the previous point, but a fuller discussion is definitely beyond the scope of the current thread. If you are interested patterns from a research and study point of view, I would strongly suggest POSA5.
Regarding the POSA book suggestion, the first POSA book gave me a very interesting definition about patterns (architechtural, design and idioms). Is also of high interest to my research to identify Bass (2003) tatics on patterns, and quality attributes, which on literature seems to be still growing.
I've noticed more work done on POSA1 suggested architectural patterns than GoF (Gamma) patterns as well.
I'm going to check POSA5 as soon as possible for more information regarding this matter, thank you for your suggestion :-)
As I agree as the pattern discussion would require much more details which is out of the scope of this thread, I would like to ask more other few questions related to software architecture and which is also related to my thread name. Seeing there are a lot of things i'm curious about things architects should know, one or other question might not be appropriated for this discussion, so please feel free to skip one or more (or even all of them) if that applies!
1. For the current state of practice, how do experts see quality attributes and architecture? To be more specific, these are my real sub-questions:
1.1 Software quallity attributes taxonomy varies among quality attribute communities (Bass 2003), SEI also has a report that dates (from 1995 if i'm not wrong)that discuss a little more about that at their website. Also, on papers there seems a constant need to state their definition so that people understand what are being talked about. How, in practice, do experts deal with this lack of standard on the quality attributes meaning, in special when it comes to architecture?
1.2 Another thing I've been curious about is regarding how software architectures measure in practice quality attributes. So far on the literature i've seen a heavy use of scenarios (methods that i believe that are or were used at industry such as ATAM from SEI, AQA, SAAM, COVAMOF and others) normally suggest them, and much less metrics. They usually discuss that quality attributes are imprecise, and requires more context which is given by the suggested scenarios. So, how in practice do experts deal with this?
2. Another huge curiosity I have is related to how architects design software architectures in practice. For example, for software architecture product lines i've come across UML notation from SEI and the views concept is prefered ; on a discussion with McGregor i've learned about ADLs is prefered, and on a discussion with David Weiss I learned about decision diagrams (which resembles feature models for product lines), sequence diagrams and simple text notation was prefered to document architecture. In general, what do experts prefer?
3. How do experts use Tatics (Bass 2003), POSA architectural patterns, and design patterns (gamma) in practice? I'm aware they're very high level guidelines to construct architectures, so i'm sort of curious if this is also a problem in industry.
4. Have you come across the term 'antipattern'? I've seen this being mentioned on the literature, but I'm also clueless if this is used in practice.
In POSA5 we revisit and critique the term "architectural pattern". It is more accurate to state, for many patterns, that they may be applied architecturally and non-architecturally than that they are intrinsically architectural or not.
As an aside, the majority of research on patterns seems irrelevant or misses the point: there's a lot of research on GoF's Design Patterns book, but this is not the same as research on design patterns as a concept or an approach.
1. Industry use of formal quality attributes is not widespread. QoS is normally described tacitly or in terms of measurements.
2. In terms of diagramming, UML is the notation used by the majority. ADLs and other formal notations are relatively uncommon. DSLs are increasingly common.
3. Patterns are sometimes used descriptively in communicating an architecture, sometimes prescriptively in defining it.
4. The term anti-pattern is one we critique in POSA5. I find it misleading and not useful. It used to be commonly used, but these days it is as likely that people will use the term "smell".
Campbell Ritchie wrote:It is quite surprising how people in industry are happy to lag behind the "cutting edge". If they have a technology which works, they will stick with it, even though it is ten years old.
Might be they are not interested to spend money.
SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!