Evolutionary architecture and emergent design: Investigating architecture and design
Considering the respectable author, don't let the title scare your away. In this first (of a series of articles) Neal Ford does a great job at defining and describe central concepts and notions such as "architecture", "architect", "design", SOA, and more. Being over-used words it is easy to be ignorant about what they really represent. However, my impression is that being ignorant about them actually says a lot about how well one understand the social process that software development is. Also, Ford pinpoints some important truths regarding software architecture, that made me go: "Exactly, that's what I always meant to say!"
I'll sum up (my perceived) highlights from the article:
- "We should stop referring to Java programming as an object-oriented language and should call it a framework-oriented language."
Yep, that's right. Being a java developer is much about knowing what's around. To prevent re-inventing (or create square) wheels. Knowing how to combine open source building blocks, and do so in ways that conform with established best-practices and patterns that will provide foundations that minimize technical debt (see below) and complexity. - Architecture: "Stuff that's hard to change later."
One of the core ideas behind evolutionary architecture is to defer decisions as late as you can. But it is all balancing on an avalanche. I liked, and recognised myself as an occational sinner of, Ford's futher notion of "Rampant genericness". "We seem to have a disease in the Java world: overengineering solutions by trying to make them as generic as possible." Being generic can be a means to defer an architectural decision or making it easy to substitute something later. But the cost of genericness is increased complexity. I think it is a good practice to keep reminding yourself of the YAGNI principle (You ain't gonna need it) :-) - Architectus Reloadus vs Architectus Oryzus
Architectus Reloadus: Powerpoint architects that last wrote code about a decade ago, and now they're making the important decisions.
Architectus Oryzus: Architects that actively contribute code to the project, pairing with other developers on the hardest parts. Their responsibilities also include interacting with other project stakeholders to make sure that everyone speaks the same language. - And for the icing of the cake: Words of wisdom about technical debt
"Compromises in your design for the sake of some external force, such as schedule pressure. Technical debt resembles credit card debt: you don't have enough funds at the moment, so you borrow against the future. Similarly, your project doesn't have enough time to do something right, so you hack a just-in-time solution and hope to use some future time to come back and retrofit it."
Compared to credit card debt, you have to repay it - quickly. Else it will accumulate - quickly. Eventually, and to take it to an extreme, it might throw you out of your home. The same thing applies to software development. One needs to be aware the importance of doing things correct as early as possible. Don't postpone refactoring. Mess is viral. If you don't get rid of it, it will spread. From my experience, suprisingly few project managers and team leads recognise the importance of handling this. The failure to do so might be disastrous for a project. My personal experience is that managers that do recognize this best, however, tend to be (former) developers/grease-monkeys themselves.
So, consider my warm recommendations and read the article yourself at: http://www.ibm.com/developerworks/java/library/j-eaed1/index.html
