|
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.
|
|
|
|
|
 Good post. Some of my take on the topic is in this post[^] from yesterday.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Marc 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
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
The 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
|
|
|
|
|
Having 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.
| Ravings en masse^ |
|---|
| "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 |
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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... 
|
|
|
|
|
Marc 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 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Refactor, or bear the costs.
|
|
|
|
|
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.
|
|
|
|
|
raddevus wrote: What you need is a system that can only be described in books and at conferences.
It's called Code Project.
|
|
|
|
|
I 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
|
|
|
|
|
Keep in mind that in some languages that use frameworks (like C#), fewer lines of code written does not always mean fewer lines of code executed. Looking at the MSIL to compare lines of code created for some particular syntactic sugar shortcut is generally a good idea.
|
|
|
|
|
And just to complicate things I'm going to chime in to say that not only does fewer lines of code not mean more efficient, the opposite is more often the case, because naïve algorithms tend to take less code but do more work.
Because of that, the framework code is often the best choice, even for performance reasons.
I wrote a B-tree library in C# for holding millions of rows of data in a dictionary. The standard dictionary outperformed it for small sizes (of course) and kept up with it all the way until millions of rows at which point it still wasn't much worse, leaving the only advantage of my b-tree was the storing of the data in sorted order.
Don't underestimate a good framework. Lean on it hard.
Real programmers use butterflies
|
|
|
|
|
I presume to be of the same style as you do but in the last project the bank tried to design everything before starting to code, the idea was that the design would actually be the pseudo code they outsource would code from. They got me to prototype the project, what took me 3 months to complete took a team of 12, 18 months to get to production by transferring the prototype code to a design tool and getting the team to code from the tool.
The prototype was a more stable solution.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Architecture 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[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
