The balance between architecture and code
-
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 Subscriptions"Design (architect) from the top down, then implement from the bottom up."
-
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 Subscriptions:thumbsup: Good post. Some of my take on the topic is in this post[^] from yesterday.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
:thumbsup: Good post. Some of my take on the topic is in this post[^] from yesterday.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
Some of my take on the topic is in this post[^] from yesterday.
Yes! I read that, and my subconscious must have been noodling on it while I slept.
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."
PIEBALDconsult wrote:
"Design (architect) from the top down, then implement from the bottom up."
While that makes sense in the abstract, I think it's misleading and results in compartmentalization. It's hard to express in words, but the activity of architecture and implementation is for me more of a process of moving around a lemniscate with fractal properties.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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 think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability. Often the requirements are not well defined or understood and it leads to an implementation that isn't ideal. That's where v2 comes in - redoing the way it was supposed to be done :)
-
PIEBALDconsult wrote:
"Design (architect) from the top down, then implement from the bottom up."
While that makes sense in the abstract, I think it's misleading and results in compartmentalization. It's hard to express in words, but the activity of architecture and implementation is for me more of a process of moving around a lemniscate with fractal properties.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsQuote:
a process of moving around a lemniscate with fractal properties
Are you trying to compete with @BillWoodruff on the poetry front? :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Quote:
a process of moving around a lemniscate with fractal properties
Are you trying to compete with @BillWoodruff on the poetry front? :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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 Subscriptions -
I think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability. Often the requirements are not well defined or understood and it leads to an implementation that isn't ideal. That's where v2 comes in - redoing the way it was supposed to be done :)
Jacquers wrote:
I think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability.
That's the funny thing - it only takes a few lightweight architectural implementations to achieve a good amount of scalability, regardless of the project. The things that promote scalability tend to be completely agnostic to the type of project, at least in my experience.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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 SubscriptionsJust 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
-
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
rnbergren wrote:
There is not a one size fits all to all projects because everything changes with each new try.
I've concluded that there are common architectural elements that can definitely be reused, and yes, there are application-specific architectural decisions as well, though in my experience, many of those can become reusable (if not in code, at least in concept) implementations.
rnbergren wrote:
Quite often Architecture changes meaningfully after the coding starts.
Yes!
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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 SubscriptionsThe metaphor that comes to mind is a diamond cutter: you need a lot of expertise and a lot of patience to do it right. But polishing each face of a diamond takes time and perseverance and both of them are in short supply in the software world. What is the chance of nailing perfectly the architecture the first time around? You see the pieces that can be reused and where each one fits only after you've travelled the design ladder from top to bottom and from bottom to top a number of times. On the other hand how many times do you have the chance to get back to a project and do major rework? In most cases the economics of the game forces you to leave unfinished bits and pieces and you move on with the sad taste of not having done your craft as well as you wanted.
Mircea
-
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 SubscriptionsHaving never actually learned to code. I just do it. So I get an image in my mind's eye (poetic interlude) and keep also the idea that I'll have to extend it at some point; it, in this case, being just about everything. It causes a good deal of abstraction and that does increase the code size a bit . . . at least at first. The whole thing about coding (not discussing language implementations) is that doing it right is just following the sensible path. Experience has embellished the path (not necessarily the code) to take into account what will happen (i.e., users) and what is likely to come. I wouldn't say it fits any particular model but it does seem to work.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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 SubscriptionsThe more players, the more up front work you need to do. Can't pivot a crowd easily.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
The more players, the more up front work you need to do. Can't pivot a crowd easily.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
And if you have a crowd, you need an application framework. If there isn't one that's a good fit, you need to build it yourself. This needs to be done by a small team, some of whom are using it to build a few serious applications so that it evolves into something relatively stable before the crowd is unleashed.
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 SubscriptionsMarc Clifton wrote:
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.
Ditto. Less, is easier to understand, maintain, service and makes it easier to track bugs. As far as I know, this is the gold standard.
Marc Clifton wrote:
So it strikes me that the missing category: well-architected, well-coded
Seen it once, in 25 years.
Marc Clifton wrote:
And by architecture, I don't mean gloriosky layers of abstractions
Yeah. This bugs me. One of those three layers is SQL Server. And still people insist on adding another layer, because the docs say so. No! SQL Server is the abstraction to how stuff is stored on disc, you don't need that layer that does absolutely nothing.
Marc Clifton wrote:
thousands of interfaces, DI and IoC.
Use them if needed, don't use them just to have it. Only use it if needed.
Marc Clifton wrote:
maximizing code re-use
To clarify something else; code re-use, means calling an existing function, not to Ctrl-C, Ctrl-V it! You call the original, having one point of maintenance. Not copying the same bloody statements all over the place.
Marc Clifton wrote:
Thoughts?
I had many bosses; one would state what he needed, and demanded minimalism. He'd just say what you should output, from his input and that's it. How you got there, was your problem (that's 25 years ago). It worked like magic. My last came with patterns, he'd paint this big picture of interactions, told everyone which parts to build, and off we was. His magic was a level up. There also was two VB6 projects. Not gonna say anything about those, as the managers were as outdated as the language. I mean, really, storing 31 booleans for each member each day, and convert them to strings? That was the only person I met with the architect title.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
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 SubscriptionsRefactor, or bear the costs.
The Science of King David's Court | Object Oriented Programming with C++
-
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 SubscriptionsMarc 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:
-
And if you have a crowd, you need an application framework. If there isn't one that's a good fit, you need to build it yourself. This needs to be done by a small team, some of whom are using it to build a few serious applications so that it evolves into something relatively stable before the crowd is unleashed.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.The "framework" is the (up front) architecture; the "crowd" includes users; and all are on the same page due to the "architecture". When everyone is responsible for their own sub-system, it's the interfaces I'm concerned about; not their CRUD framework.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
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 wrote a new post that touches on this on the top. It's kind of related but different enough that I thought it warranted its own post. Anyway, I agree with you that architecture is something that is done throughout the lifecycle of the project. You do want to front load your project with a design phase, but you don't freeze the design before you write the code. I think people tend to believe you do. You freeze *features* hopefully. But design is living.
Real programmers use butterflies
-
Jacquers wrote:
I think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability.
That's the funny thing - it only takes a few lightweight architectural implementations to achieve a good amount of scalability, regardless of the project. The things that promote scalability tend to be completely agnostic to the type of project, at least in my experience.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsMarc Clifton wrote:
it only takes a few lightweight architectural implementations to achieve a good amount of scalability, regardless of the project.
If only assiduous study of your work could get me ... there ... the limit in this case is the student, me, not the guru, you ! cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
