In this chapter, the author tells the story of two comparable projects but with very different outcomes: one failed miserably requiring a rewrite while the other one successful even after many revisions. To me, the most important factor is to have everyone having the same big picture.
This is much easier said than done. From personal experience, even a relatively simple diagram can be interpreted differently by different people, even after numerous meetings and even when everyone agrees! It is very dangerous for an architect to have a false sense of group agreement.
A few words on the technical debt. My experience is that technical debt is hardly ever repaid especially in a large-scale software development. Typically in a large development the responsibilities of each team becomes very specific: with each team responsible for a module or a single aspect of the overall product with separate testing teams, regression teams, system testing teams, etc. Suddenly repaying the technical debt requires buy-in from multiple teams. One would not want the testing manager griping about rerunning the same tests and the schedule impact. It is equally difficult to justify to the upper management the additional time to work on something that's already "working".
Saturday, August 29, 2009
Thoughts on Beautiful Architecture ch. 1 - What is Architecture?
This initial chapter focus on the overview of software architecture. It is interesting that the authors state that "architecture is a subset of design" especially since I have come across the question on architecture vs. design multiple time and still don't have a clear-cut answer to it. The statement certainly make sense intuitively as I often imagine software architecture as the high-level design focusing on inter-component structures with the goal to fulfill all user requirements.
The chapter also asks the question on who to make architectural decisions. This strikes me as the typical question on top-down vs. bottom-up. The book seems to suggest an architect should do it to preserve conceptual integrity. No doubt the end product of the top-down approach will be more consistent to the original blueprint. However, does it mean that it must be a better product? I think the Agile programming methodology in contrast can be seen as a more bottom-up approach and many would argue it is much more flexible in meeting ever-changing requirements. Also, taking an example in biology, all complex biological beings are a congregation of individual cells which at one point of the time are individual uni-cell organisms that then evolve to corporate and to co-exist together. There is not a master plan and the only driving force is to constantly adapt to the new requirements (to survive in constantly changing environment). Yet don't all come out pretty well?
From the short story at the end of the chapter, the authors seem to say that an architect should still code, to get his or her hand dirty. I agree with the authors and I think this is the best prevention for an architect becoming idealist and elitist.
The chapter also asks the question on who to make architectural decisions. This strikes me as the typical question on top-down vs. bottom-up. The book seems to suggest an architect should do it to preserve conceptual integrity. No doubt the end product of the top-down approach will be more consistent to the original blueprint. However, does it mean that it must be a better product? I think the Agile programming methodology in contrast can be seen as a more bottom-up approach and many would argue it is much more flexible in meeting ever-changing requirements. Also, taking an example in biology, all complex biological beings are a congregation of individual cells which at one point of the time are individual uni-cell organisms that then evolve to corporate and to co-exist together. There is not a master plan and the only driving force is to constantly adapt to the new requirements (to survive in constantly changing environment). Yet don't all come out pretty well?
From the short story at the end of the chapter, the authors seem to say that an architect should still code, to get his or her hand dirty. I agree with the authors and I think this is the best prevention for an architect becoming idealist and elitist.
Wednesday, August 26, 2009
Hello World
Welcome to my blog. I am a MCS student at Univ. of Illinois at Urbana-Champaign. This semseter I am taking CS527 - Adv. Topics in Software Engineering and I'll be blogging mainly about various readings and related topics in Software Engineering. Please stay tuned.
Subscribe to:
Comments (Atom)