The balance between architecture and code
-
For so long I've been an interface aficionado. But I keep rediscovering C++ and with it generic programming, and template based metaprogramming which I find profoundly useful for generating efficient flexible code I couldn't easily make otherwise. The powerful thing about this is that this "polymorphism" is source level, not binary (vtbl based). The problem with this is all of this "polymorphism" is source level, not binary. The compiler checks it, but only if you use it by instantiating it and that means you might not catch errors in your code until well after your code is being used, even in production, because that part never was compiled. So you lose a big advantage of interface based programming when you're using generic programming and template based polymorphism to implement your "interfaces" which again are source level, not binary. I can't resist the urge to use it though. The power. The efficiency. The dark side... it beckons!
Real programmers use butterflies
Where angels fear to tread... :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
After a recent post, it occurred to me that we rarely see a good balance between architecture and code. I often see: under-architected, over-coded. But I've also encountered: over-architected, over-coded. Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding. So it strikes me that the missing category: well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded." And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.) Thoughts?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsArchitecture and code are for me on the same side of the balance, together with testing. On the other side are the requirements, including user stories and business case. The balance is in short: WHAT ---- HOW With ATAM (Architecture Tradeoff Analysis Method) one verifies this balance in different ways, - Does the architecture fulfill all the requirements? - Does the architecture have more/less than needed? Why? - Do the requirements define all (non) functional details needed for the architecture? - Are there missing requirements that can be derived from the architecture? (e.g. the ones so obvious that they are not mentioned) With respect to the architecture, (imho) if a programmer can code it, and a test engineer can create a test specification and the requirement engineer can track the requirements, one may stop specifying the architecture. Yes, iterations will follow to improve readability and maintainability. If the test specification cannot be derived (or seems odd etc), the architecture is probably missing something, often indicating you need to get back to the requirements / stakeholders. So there is also an important balance in the HOW part between the architecture and the test specification, that may trigger an unbalance in the HOW - WHAT balance. ATAM Architecture tradeoff analysis method - Wikipedia[^]
-
After a recent post, it occurred to me that we rarely see a good balance between architecture and code. I often see: under-architected, over-coded. But I've also encountered: over-architected, over-coded. Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding. So it strikes me that the missing category: well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded." And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.) Thoughts?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI had been there so many times that it just screams to me all the balancing only experience taught me. Usually learning materials are not really in touch with reality and all the ways it can variate. My experience is that: 1 - The first step is to try anticipating the scale and lifetime of a project. This will help avoid unnecessary over or under-engineering. Patterns exist to help us, but they are often not worth the cost and can create a huge technical debt in the team. 2 - Code reuse is a double edged sword. It can both help to prevent bugs, but also create bugs. When dealing with complex systems, creating a single business rules model can be very bad. You start twisting and over abstracting so much that the codebase starts becoming very hard to understand, creates a lot of coupling and unpredictable side effects. Applying DDD here is beneficial as you separate an often "Big Ball of Organized Mess" into smaller more manageable contexts (bounded contexts). That will somewhat generate code duplication, but I believe it to be a good thing as the chances of side effects are greatly reduced and allows different business domains to evolve independently. Of course, this requires some mindfulness on the impact of a change in the big pictures, but scenarios like the one below are so much easier to deal with, that's worth the code repetition (and some times data): Consider a hypothetical system where we have an employee class which are part of two different business domains: 1 - Payroll Management: For payroll management, you need a model that contains properties like: salary, working schedule, name, address, tax number, email. It should contain methods like calculatePayrollTaxes, calculateNetSalary, calculateIncomeTaxes, updatePersonalInfo 2 - Sales: For sales rules you likely need a whole different approach for the employee rate. For example. In a commissioned scheme, you'd need the following properties: commission rate, name, mtdCost. The methods could probably be much more focused like just having calculateCommission. Because the P&L report needs to account for the costs of the employee, a change in payroll taxes, salary or work schedule will affect the month to date costs. But that can be kept in its entirety contained within Employee entity of the Payroll Management context, without having a huge class with all rules that involve employees. It makes a lot easier to maintain its business rules, doesn't require and endless number of abstraction layers and has much lower chances of causing side effec
-
After a recent post, it occurred to me that we rarely see a good balance between architecture and code. I often see: under-architected, over-coded. But I've also encountered: over-architected, over-coded. Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding. So it strikes me that the missing category: well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded." And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.) Thoughts?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI'm almost on the same page, but I also avoid code re-use when the data is different from a functional point of view. When 2 areas have different use cases and (functionally) different data sets, but can use the same code initially, I just duplicate the code I need and give it a name that's more appropriate for the specific area. Most of the time, the functions start to drift apart along with new business requirements. By splitting it up initially, I avoid having to add logic to differentiate between both areas, something that typically happens over time, and causes bugs when done poorly. Also, I align my structure with whatever report / graph / property or other business object that gets identified, because that's where your design changes come from in the first place. For the same reason I avoid purely-technical abstraction layers and objects that have no representation for the end user, except for one specific case. To me, technical abstractions are only useful as a way to divide work between teams (including external teams which I have no control over) and should be implemented, evaluated and maintained as such. As an example, you could have 2 teams in a product, let's say UI and backend, and use 3 business critical open source packages for reporting purposes. A good structure would then have 5 critical abstractions under the hood to separate those concerns. In this case 2 layers with some rules that work for both teams, and 3 class encapsulations. I know I sound extremely pragmatic, but the compiler doesn't care about people and doesn't care about profit, and I care tremendously about both. So that's what a good structure should add, in my personal opinion.
-
After a recent post, it occurred to me that we rarely see a good balance between architecture and code. I often see: under-architected, over-coded. But I've also encountered: over-architected, over-coded. Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding. So it strikes me that the missing category: well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded." And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.) Thoughts?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsFor me "good architecture" means making something easy to debug when it breaks, because it will break and I spend much too much time trying to debug cleverly architected code.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Greg Utas wrote:
Are you trying to compete with @BillWoodruff on the poetry front?
Bill takes all the poetry awards on that front!
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsNot to mention the back, sides, top, and bottom!
Software Zen:
delete this; -
Marc Clifton wrote:
well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded."
But how would you? : 1) sell books 2) sell tickets to your conferences I mean without that you're just writing software and getting stuff done. What you need is a system that can only be described in books and at conferences. :rolleyes:
raddevus wrote:
What you need is a system that can only be described in books and at conferences.
It's called Code Project. :laugh:
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
"Design (architect) from the top down, then implement from the bottom up."
Design (architect) from the top down, then implement from the bottom up. This statement should be refactored a bit. Try "After the intended Architect understands the strengths and weaknesses and capabilities of the proposed technology stack as fully as possible", architect from the top down, Then implement from the bottom up and refactor the entire stack as soon as the "Real" tech stack is better understood. Then race to understand what new direction the industry is heading this month and refactor yet again to be ready for it. Rinse and repeat.
-
Just start Coding while we figure out what we need. There is a balance. But only a few ever achieve it and then only for like one project or so. There is not a one size fits all to all projects because everything changes with each new try. Even if the people are the same. The experience is different. But usually everything changes. I do agree about one point for certain. Quite often Architecture changes meaningfully after the coding starts.
To err is human to really elephant it up you need a computer
One strategy I've used is to implement the simple, basic stuff first and leave the harder, more complicated stuff for later. This accomplishes two things: First, management is happy to see "stuff" being produced. Second, it gives the customer and management time to reconsider, redesign what they think they want/need. Third, it gives me time to research and develop better techniques for the hard stuff. Fourth, the hard/complex stuff will frequently change between project start and the time it is needed.
-
After a recent post, it occurred to me that we rarely see a good balance between architecture and code. I often see: under-architected, over-coded. But I've also encountered: over-architected, over-coded. Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding. So it strikes me that the missing category: well-architected, well-coded is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded." And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.) Thoughts?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsYou know you're doing it properly when the architecture and the code are the same thing.
