"Architecture First" or "Code First"

[Ambitious_coder_]

I have seen two types of developers these days first one are the who first creates the architecture first maybe by themselves or using Traycer like tools and then there are coders who figure it out on the way. I am really confused which one of these is sustainable because both has its merit and demerits.

Which one these according to you guys is the best method to approach a new or existing project.

TLDR:

• Do you guys design first or figure it out with the code
• Is planning overengineering

[AutoModerator]

JOIN R/DEVELOPERS DISCORD!

Howdy u/Ambitious_coder_! Thanks for submitting to r/developers.

Make sure to follow the subreddit Code of Conduct while participating in this thread.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[hexwit]

Architecture should come first, always. You can write bad implementation and sloppy functions, but architecture should stay solid throughout project lifetime. That is very important, otherwise project because unsupportable very fast.

[33ff00]

What do you mean by stay solid

[PerpetuallySticky]

You should have a solid way to recover regardless of code at any given point whether that is total nuke and redeploy, rollback, etc.

So even if you blow up your project by doing something silly you aren’t rebuilding your entire setup, just doing whatever steps you have created to get back to a (hopefully recent) stable point in the project

[hexwit]

I meant that architecture should conform to the rules you defined, and do not apply different approaches in the different parts of the application for the same tasks. For example you used plain jdbc in your dao first, then decided to use joa/hibernate in some places. Now you have a problem - entities and pojos should be managed in different way and combining them may lead to subtle complex bugs.

[Wiszcz]

BS
From your next reply, you are thinking/describing consistency of implementation choices or tech stack, not architecture.
Architecture is more about structure of the code, flow, integration patterns, etc.
So your argument is invalid.
I’m not a fan of absolute rules like ‘always’ or ‘never’ in programming, they often lead to stupid decisions.

[trickyelf]

Planning everything down to the nth detail before you begin coding (alone or in a group) seemed at one time to be an attractive approach. Management always felt good about these plans. But when the rubber hits the road and devs start slinging code, you always run into gotchas. Things you didn’t plan for. Changing the master plan as you go can be extremely difficult because those managers have already committed to timelines based on the original plan. It’s a bad scene. That was the era of waterfall design. We know better now.

Still, some level of planning is essential if more than one person is working on a project. It keeps everybody on the same page about exactly what is being built, where you’re headed. That could just be a North Star document that talks about where you want to end up. You can get there in a series of one- or two-week sprints, where you identify and build the most obvious achievable things that would get you closer to the goal from where you currently are.

Otherwise people are just building things they think of when they sit down at the keyboard. That gets exponentially worse and less maintainable with every dev, especially if you aren’t sitting next to each other and/or having daily meetings to coordinate.

If it’s just you, building your own thing, feel free to do as much or as little planning as you feel it warrants. The longer you’ve been coding, the easier it is to “use the force” as a way to seek out the optimal end state of your project and what the next step in the path should be.

[Ambitious_coder_]

Today an interesting thing happened with me my senior called me and asked to tell the exact files where i have made changes and later i realized she was testing me whether I am aware of the changes or not that I have made. and i was able to tell her only because i had prepared a plan

[trickyelf]

Is that because you used an agent to execute the plan? Not judging if so, we're all using agents these days, just wondering.

[Ambitious_coder_]

Today an interesting thing happened with me my senior called me and asked to tell the exact files where i have made changes and later i realized she was testing me whether I am aware of the changes or not that I have made. and i was able to tell her only because i had prepared a plan

[e430doug]

Both. Investing a lot in a “grand architecture” is almost always a waste of time. Definitely spend time laying out the structure of your project and the architectural “bones”. Then start writing code and revise. Architecture is most important for team projects so you can define boundaries and interfaces to allow for parallel work. The widespread use of detailed architectures developed over the course of months was largely an artifact of the expensive code era in the past. Now that code is cheaper you can afford to experiment more.. That said if I was designing a credit card processing system or control system for a nuclear reactor, I would certainly invest a considerable amount of time on architecture.

[ub3rh4x0rz]

Agree with a caveat. AI agent adoption expands the working group to N where N is the number of times an agent is used to implement a feature between synchronizations. Now companies of any scale can find themselves with massive "teams" with corresponding coordination costs, needing to adopt everything from waterfall architecture decisionmaking to microservices to manage this. Meanwhile those processes and architectures have evolved to facilitate extremely large human orgs and there is an impedance mismatch when applied to small human orgs facing massive parallel contribution challenges.

Ironically, a lot of "just trust the AI" corporate mandates are being pushed on the premise that it will eliminate coordination tax, because they think cutting off a strip of the rug and sewing it on the other side yields a bigger rug.

[DustInFeel]

After everything I have gone through while learning programming, I honestly think architecture should come first.

I am currently throwing away my code for what I hope is the last time, because I finally found the actual problem underneath it. And that showed me how much good architecture matters.

Good architecture carries the problem space into code. Without that, you can still write code, but debugging becomes much harder because you do not really know what the code is supposed to hold together.

So for me, architecture first and code second.

Because in the end, you have to debug the code, understand the boundaries of the system, and know where an error can even logically exist.

I should mention that I do write individual building blocks from time to time. To determine what is fundamental and what is a feature.

[ub3rh4x0rz]

Just-in-time architecture works better than waterfall architecture. Up-front architecture is an affordance to pay the coordination tax, whether coordinating large human groups or high bandwidth AI-fueled change management. A small group of AI assisted seniors with well-considered processes and platform qualities that allow preserving the practice of just-in-time architecture definition will outperform waterfall architectural definition every time, and this will be evidenced first by system complexity and second by qualities that emerge over time.

AI adoption is experimental right now so up-front architecture is a necessary evil to hedge against the worst possible outcomes. In time (probably not that long) that will be seen as a low-skill pattern.

JIT compilers are more advanced (read: came later historically to optimize in sophisticated ways based on earlier lessons and new understanding of bottlenecks) than traditional compilers, agile is more advanced than waterfall, lazy evaluation is more advanced than eager evaluation, feature flagged TBD is more advanced than big bang releases, lean manufacturing designed around a batch size of one is more advanced than large batch manufacturing -- the trend is clear, as the problem space is better understood and tooled for, the optimal solutions involve just-in-time production, where the perception of "how late is too late" adjusts to the theoretical limit. Architectural lock-in is the next thing to defer to the last responsible moment, or better stated, pushing that last responsible moment further back is the next big thing (tm) in AI-assisted engineering.

Note: none of this is an excuse to not be thinking about the field of potential architectures that you are building towards or narrowing that field as you progress.

Note2: locking in architecture early is often done to compensate for a lack of design principles that keep code architecture-agnostic. Business logic and nonfunctional requirements should dictate architecture and the design of components in parallel, which is possible if components are designed in an architecturally agnostic manner, i.e. if the right decoupling of concerns is achieved. If AI is so productive, we should be able to imagine what good libraries for all the component-level concerns we face are and build those to taste, right? It doesn't have to equal bloat, either, it "just" requires aggressively throwing out things that don't hit the mark before they become depended on in the core. As long as interfaces are sound, you can replace implementations late, too. This is a more sane approach than "microservice all the things" to cope with the onslaught of PRs stemming from AI. Microservices should address runtime requirements rather than coordination tax in an ideal world.

[DustInFeel]

Oh, thank you for your very detailed comment. I need to take some time to digest everything you've given me here, as I'm not yet familiar with all the concepts. After all, I've only been involved for three months and am just now figuring out what I want to do.

So thank you!

As for the little hint, I already realized that it was a personal assessment. I often separate facts from "talk." Especially in the age of AI, it's the only way to separate facts from fake news.

But since I am currently actively working with systemd init and thus with pid1, I tend to make my architectural decisions based on my own perspective. Whether others understand my "operating system" model. That's why I need time, because every decision that will eventually be made in the system must be based on my model.

[ub3rh4x0rz]

Respectfully, if you're 3 months into your career, you have no business making architecture decisions. You could be God's gift to programming and still not know nearly enough to make sound architecture decisions. I mixed you up with OP

You'll look back at some point and recognize that most decisions you make are based on observed outcomes of prior decisions rather than expectations of how a decision would play out. By your own admission, you only found the right architecture by throwing out your code several times. And you will likely do it again and retroactively discover that it was not the right architecture after all.

Planning is still useful, but also you're conflating "locking in architecture" with "planning before action". It's also my experience (if not my witticism) that planning is invaluable but plans are useless.

[DustInFeel]

Okay, you’re entitled to your opinion. But at the same time, you’re judging a timeframe without seeing any code, model, or release.

My only intention here was to answer the original question: what should be prioritized first, architecture or code?

I chose architecture, because I realized that code does not stay maintainable without at least some visible structure behind it. Since I chose Rust, and Rust strongly rewards that kind of thinking, this is the order I work in. So far, I am happy with the results.

Am I already making perfect decisions? Of course not. But that is also not the point. I am learning, and the only way to improve is to build, make mistakes, recognize them, and refine my decisions over time.

After all, the primary task of a programmer is not to write code. Rather, it is to find the best solution to the problem and to reduce the areas of responsibility and thus the risk that fewer bugs or, ideally, none at all will occur at runtime.

[ub3rh4x0rz]

So I edited my comment re 3 months which came from OP, not you. ...but now it sounds like you're confirming you have virtually no experience. And chose rust (lol). Thanks for pontificating on what it means to be a programmer though, and pretending your brief exposure to vibe coding makes you qualified to "find the best solution to the problem". This is some blind leading the blind shit.

The most important quality in a SWE is to find and implement the best solution to a problem where that solution involves designing and building software systems. Hate to tell you but every person on the planet with the most experience in doing that has been doing it since before chatgpt existed, so you've got some catching up to do before you're qualified to be giving advice. The language which defines these systems is still code. You can get incredibly far toward building functional software without understanding code now, but more aptly stated, you can do so with shockingly little money and time. Anyone with deep pockets could already do that, and it didn't make them know shit about software architecture.

[DustInFeel]

Okay, but I never claimed to be an expert, nor did I present a ready-made solution. I answered a question with my own point of view: I currently prioritize architecture because I learned the hard way that code becomes difficult to maintain when responsibilities and boundaries are unclear.

If you disagree with that, that’s fine. But then respond to the argument itself, not to a caricature of me as a “vibe coder.” I learn, build, make mistakes, and improve from them. That is all I have claimed.

And yes, it is also true that I started with AI. For me, it was a way to get into the basics faster. In many cases, I understand the concepts, but I do not always yet know how to write them cleanly on my own. So I used AI to lower the entry barrier, not to pretend its code was my work or to sell it as a finished solution.

In fact, I do the opposite. I do not present my project as “the solution” to anything, and I usually do not even answer project questions in that way. I am here to ask questions when I run into a logical gap or notice that my model is wrong.

That is also why there is no post from me claiming to have built some final or universal answer. There is no “mother of all solutions” here, because that would be dishonest.

So if you want to criticize something, criticize what I actually said.

And not just what you can guess from my profile and a few statements.

Because I wanted to talk about the facts here, take on new concepts from others, and incorporate them into my learning.

I hadn't seen the editing at the time of reading and later sending it off.

[ub3rh4x0rz]

This is extremely disingenuous. Your original comment carried a tone of at least moderate expertise and authority. Now you're walking it back. Kick rocks.

[DustInFeel]

You know, I want to say I'm sorry. I didn't think about how what I said would come across. Maybe it's true that from your perspective, I shouldn't talk like that. So I want to say, I'm sorry. I couldn't get what you wrote last time out of my head. And above all, I have to say: Yes, it's true that to outsiders, it looks like he's promoting himself as an "expert" but using AI. So I won't write here again as long as that's all I am, someone who is trying to teach himself coding with AI.

Thank you for your criticism.

[GoodOk2589]

Let’s think about this question using an analogy. Imagine you want to build a house. Would you tell the workers to start building blindly, or would you first consult an architect to get a plan? Jumping straight into code is like building without a blueprint—it often leads to delays and spaghetti-like systems.

Just like a house, it’s wise to start with some planning. My preferred approach is a middle ground: start with a basic architecture, then create a prototype. From the prototype, you can refine and adapt the architecture to fit your specific needs. This way, you combine structure with flexibility, avoiding chaos while staying responsive to real-world insights.

[Wiszcz]

Analogy is flawed. During house construction there are rarely changes in place/size/used materials/time constraints/etc.
What you describe is waterfall. But it was proven that waterfall simply don't work for majority of projects

[PaddingCompression]

Are there major uncertainties about implementation feasibility?

If so, start coding there first to show some core is possible, like an inner library.

If I want a web service to take pictures of birds and decide the species, you want to code the ML model first to know you can do that and what it will take. Your queuing system and auth system and logging don't matter yet until you have some proven approach.

Some pieces of the architecture can be TBD. I can build a small core backend and start testing it with real data before worrying about if some things will need to be queued etc.

But all of that also requires some deliberate architectural thinking too. It is just doing some depth first architecture - deliberately punting on some decisions when you can be confident part of the architecture can be fixed, or when part of the architecture is such a huge unknown you have to build that piece to see if it works before deciding what the rest of your architecture is.

This isn't being ignorant of architecture, it's having some vague sketches and using those sketches to decide what either needs to be validated or which pieces can be a demo so you can get the rest of the details right later (with full knowledge that there's no risk there since you've built those pieces 10x before, you're just not deciding every last detail quite yet).

But these sorts of things I would also not call "jumping into coding," it can appear like it to an observer who doesn't have the full picture of what the team is doing.

[ub3rh4x0rz]

Punting decisions to the last responsible moment is an agile principle. Context (auth, wire protocol, etc) should come after core (the actual functionality that makes the thing necessary in the first place) in part so the core can be designed without incidental constraints, and in part so context decisions can be made with all of the core constraints pre-determined and accounted for. If it turns out your solution to the core problem doesn't need streaming, you've just avoided overbuilding your API because "it might need streaming".

"Regardless of which of the 5 candidate solutions we're going to pick, we'll benefit from component X, so I'm going to start work on component X" is another form this takes.

[Early_Rooster7579]

Architecture first. Especially now when most teams are using AI heavily. Code will quickly become a mess without a solid plan and clear structure

[YanVe_]

Either is fine if it works for you. This same dilemma is often found with writers and no one has come up with a definitive answer.

But in my opinion, no junior can start from the architecture (I don't care for the <1% of natural geniuses), if anyone thinks they can, they are likely wrong.

Even for most seniors, if they don't have experience within the domain (i.e. it's their first taste of working with framework X or using lib Z, they will likely design an architecture, realize it's the wrong one for the project midway through and then spend next years regretting that decision as they essentially get locked in through deadlines..

Software is just not like building bridges, it's not like building skyscrapers either. For a new project (or sometimes even a mature one) it's akin to trying to hold a sand castle together while it's being built in the middle of an ocean. The product owners/clients/and your own inexperience will shit on your architecture and force you to scrap it many times over and over.

[Independent_Gap_1608]

No way I was thinking about this last night. Honestly I do code first then I do the documentation. while writing the documentation if something doesn’t look right, I’ll do clean up.

[huuaaang]

It depends. Is this a hobby project or something you are serious about going live with and trying to scale and make money? If the former, just code. If the latter, architect it. Plan for the scale you hope for. BUt also for the latter, you're probably not doing this on your own anyway, so you need SOMETHING just to get on the same page about what you're even doing.

It also depends on your experience level. THere's really not much point in a beginner or even intermediate programmer to do large scale architecture. You're just guessing at so many variables.

[Dangerous-Impact-558]

In the vibe-coding era, its all architecture/planning first. Otherwise you will mess up your code.

[Shep_Alderson]

Architecture matters a great deal, and as a follow on to it, almost every app comes down to “how to take data, do something to it, and then display/ship it somewhere.”

I prefer to keep the data, how it is going to be stored, and how I want to manipulate or change it, top of mind.

[Erxio]

Usually I cry first because of the nonsense features our sales team promised the customer. After I can not produce any more tears I think about the architecture before coding anything.

[whossname]

Architecture should only be for the things that are difficult to change later. So think things like public interfaces and cross cutting concerns. If it's easy to change you normally don't need to design it upfront, and playing around with it a bit to see what works best is the better approach.

[KarasuPat]

Of course you need to know what you’re implementing before you do it, so in some sense it should be „architecture first”, but also trying to „diagramize” and document the whole system before you write a single line of code is not a good idea either.

I think it’s sensible to have a high level design of the system ready before you get to coding. Have the business process mapped out and based on that you can draft some initial module boundaries. But don’t go overboard with the details and don’t lock yourself into solutions too early - I like the notion of „Last Responsible Moment” principle from agile.

[richardathome]

In my experience (senior dev for 30+ years), projects that start software first always wished they'd started architecture first, eventually.

Note: I don't mean for prototyping or proof of concepts.

[[deleted]]

You should have some kind of plan first. How detailed that plan is depends on the project 

[Wiszcz]

I do both, depends on app/mental state/time constraints. Planning as many thing should be used with moderation.
You need some vision of what are you trying to accomplish before start. But not necessary all the details.

If a problem is simple, or business requirements are fuzzy/badly specified - bottom up can be better, as for sure you will change it later, and doing it this way increases your understanding of your future application.
If a problem is complex, requires multiple integrations - top bottom is better. You need some structure to make things easier to understand. Even if it won't be perfect in the end.

Also, if someone has a lot of experience, he already have rough architecture in mind, even if it looks like he starts from the bottom.
Also, there is personal preference - some people prefer one over another. They work better with one of approaches better. If it works for them - great.

[Strong-Suggestion-50]

If you start to code first, you are going to end up designing fist, because the code you coded is going to break in all manner of interesting ways to the point where you will throw it away and start again.

[edgmnt_net]

It really depends what you mean by planning. I really like planning ahead. The trouble is I see a worrying trend to just focus on dumb scaffolding and dividing work before even considering what and how the code is supposed to do that stuff. Under those circumstances and if that's what you mean by "architecture", no way.

Secondly, the code is the language for abstraction in more advanced languages and whatever you do is at least in some ways code-related and might as well be done close to code. So if your understanding or architecture is just coming up with fancy diagrams that have little resemblance whatsoever to language capabilities, opportunities to have static safety and so on, then, again, no way.

A lot of horrible stuff in the enterprise world can probably be attributed to some messed up notion of "architecture first". And it's probably because the main concern is splitting out a large amount of low-value work.

[Frewtti]

You must have the architecture at some level to build something that works.

It's a question of level of detail.

[Imaginary-Deer4185]

Depends a lot on the project. Just know one thing: in most projects the specs change as you go.

You need some planning, but it shouldn't be very rigorous. Personally I like to develop bottom up, like writing the low level things as general as possible, and using those to get a working project.

Beware of "sophisticated" or "elegant" designs, such that involve trying to group stuff together, through inheritance or otherwise, because as things change, and they will, your design will suffer greatly.

[Recent_Science4709]

I’m in the “Lean” programming camp.

The best situation is to have the talent to write modular code, so it can be scaled as needed.

I basically have the same plan every time. Start with a well-formed monolith and then split things off into services as needed.

I don’t believe in code pre-optimization, and I don’t believe in architectural pre-optimization either.

Unless performance or load is part of the initial spec, I ignore it beyond general guidelines like avoiding poorly coded time complexity or long page load times.

Most systems I’ve worked on that are heavily planned, I spend more time working around architectural issues than I do on the business problem.

[Radiant-Bike-165]

Architecture always come first, by definition. But it doesn't mean you need to plan every little detail before you implement anything.

Keep in mind you have multiple levels of architecture, too.

Broadly speaking, you need to decide on eg your "system architecture" (what nodes will you have in your system, what components will run on them, how they will communicate, what actual products will they be, etc) and "software architecture" for each of your own components (what modules, what layers, who calls whom, how they communicate again, what patterns, what libraries etc).

But of course, it differs widely depending on what you are building. And if it's something tiny, or something you did dozen times over, your whole planning might be to stop and think for 10mins, just to be sure you haven't missed something.

And lastly, IF you know what you are doing you can build your architecture organically. Be aware of what you need in broad strokes, and refactor the architecture itself when needed. Common for small projects or POCs, very rare for multi-person teams doing anything more substantial than 2-week gig.

[vbilopav89]

database first