IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
On those complex systems in particular the problems start long before any code is written.
A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.
For the first group code was never the hardest part. For the second group there was never any other part.
I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.
No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.
Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.
The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.
The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
> but many details
Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete.
> Code is a form of low-level design and is where the rubber hits the road.
Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it.
> The best requirements, designs, marketing, etc are worth jack if one fucks up the code.
Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing?
Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
How does not everyone understand this? It's why waterfall development never worked.
I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
That’s because fundamentally you need those strategic items to have space to do those particular detail items. If you have the best strategy and no execution, you can probably hire for that. If you have no strategy and decent execution, you are driving the Titanic into the iceberg.
> stakeholder buy-in
Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.
I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.
Getting to a state where those assumptions are true is HARD. And takes a lot of careful programming.
Yes. Once it is true, the code is easy to write. But only because a lot of effort went into making it easy. And keeping it easy is also hard. Without focused effort to keep the code clean and easy to modify, it starts to rot.
> IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
You've really seen a web software product die because of performance issues?
Healthcare.gov was a national scandal due to poor performance related to bad requirements gathering.
The $32M Hertz scandal
The $480M bug that killed a trading company in 12 secs
Challenger
Probably a bunch of stories from healthcare
Web software I don't know but there are many "modern software" that were meant to replace COBOL code running on AS400 that ended up never making it to production because they were running so badly and projects ended up being money pits.
Friendster
Wave waves at you from the grave.
Did Wave have performance issues? I thought it was amazing, they just killed it because it didn’t have enough adoption
Yes, it is hardly ever the web-side of it though.
Knowing what to do “wrt the code they write” is directly consequential to knowing what do at all, you proved the original point correct.