5 ms·

> 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

by buran77 2mo ago

> 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.

blub 2mo ago
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.
- buran77 2mo ago
  > 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.
  - Tallain 2mo ago
    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.
    - blub 2mo ago
      I don’t think anybody except those working with e.g. DO-178B or ISO26262 does BDUF. Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.
  - blub 2mo ago
    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.
- geon 2mo ago
  How does not everyone understand this? It's why waterfall development never worked.
  - MomsAVoxell 2mo ago
    Waterfall works as well as the person implementing it, which is to say it is a human process and vulnerable to typical human flaws. I have used waterfall for decades to ship millions of dollars worth of software. If you don't want it to work it won't work.
    - geon 2mo ago
      You actually planned everything in advance, and didn't have to go back and correct mistakes? Because if you ever go back a step, it is no longer the waterfall model, but an iterative process.
      - buran77 2mo ago
        > Because if you ever go back a step, it is no longer the waterfall model By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something. Look, I think I get your point but you seem too stuck in some formal definition riveted with assumptions to understand the other side. If you build a house you can correct some things after the fact. You forgot a power outlet or a light fixture? You need to move or resize a window? Probably fine and even decently low effort. You realize your foundation is too thin or too small? You forgot about one room? You put the bathroom on the wrong side of the house? Not so fine and definitely not low effort. The state of software development is so bad because so many devs just jump head first into writing code and in the end they deliver a pile of barely held together shiny bits that technically works but is a pain to modify, extend, maintain, secure, extract the expected performance, etc. All because there are 100 brick layers and not one architect or engineer on the team.
        bossyTeacher 2mo ago
        > By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something. I think he means before the official release.
kcexn 2mo ago
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.
- pjmlp 2mo ago
  In the countries where Engineering is a professional title and not something people decide to call themselves, we still know the difference.
  - kcexn 2mo ago
    In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?
    - pjmlp 2mo ago
      In many, I am at least aware of Portugal, Germany and Canada. https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60650 https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60... https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-ingenieurin-nennen https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-... https://engineerscanada.ca/become-an-engineer/use-of-professional-title-and-designations https://engineerscanada.ca/become-an-engineer/use-of-profess... You can call yourself engineer if you feel like it, however in case it comes to some court case due to liabilities and such, there might be some issues coming up with having Eng in that contract signature. Many here would probably say that they have never did the exam, and nonetheless use the title, which is as mentioned, not an issue as long as you don't land in court and the validation of title doesn't come up. Also in most European countries, being an Engineer even if not professionally qualified, automatically means that the person in question took a university degree in engineering, on an university whose engineering degree was certified as such by the government organisation responsible for all engineering professions.
      - 2mo ago
rockemsockem 2mo ago
I agree that all those pieces are important, for sure. But it can all be undercut by a few for-loops that don't consider string re-allocations. That covers the "don't understand good code in the slightest, make big mistakes" side of things, but the other side is being able to think about the algorithm that is being run in your system (sometimes across multiple layers of code) and writing code that eeks out the highest performance from the system you're on in the programming language you're using. Also, to be clear, "the algorithm" here doesn't have to be super complicated or theoretical it can be as straightforward as assembling some data structure in response to a user's query across a few different sources. That process requires being able to write good code.

by buran77 2mo ago

blub 2mo ago

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.

buran77 2mo ago
> 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.
- Tallain 2mo ago
  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.
  - blub 2mo ago
    I don’t think anybody except those working with e.g. DO-178B or ISO26262 does BDUF. Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.
- blub 2mo ago
  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.
geon 2mo ago
How does not everyone understand this? It's why waterfall development never worked.
- MomsAVoxell 2mo ago
  Waterfall works as well as the person implementing it, which is to say it is a human process and vulnerable to typical human flaws. I have used waterfall for decades to ship millions of dollars worth of software. If you don't want it to work it won't work.
  - geon 2mo ago
    You actually planned everything in advance, and didn't have to go back and correct mistakes? Because if you ever go back a step, it is no longer the waterfall model, but an iterative process.
    - buran77 2mo ago
      > Because if you ever go back a step, it is no longer the waterfall model By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something. Look, I think I get your point but you seem too stuck in some formal definition riveted with assumptions to understand the other side. If you build a house you can correct some things after the fact. You forgot a power outlet or a light fixture? You need to move or resize a window? Probably fine and even decently low effort. You realize your foundation is too thin or too small? You forgot about one room? You put the bathroom on the wrong side of the house? Not so fine and definitely not low effort. The state of software development is so bad because so many devs just jump head first into writing code and in the end they deliver a pile of barely held together shiny bits that technically works but is a pain to modify, extend, maintain, secure, extract the expected performance, etc. All because there are 100 brick layers and not one architect or engineer on the team.
      - bossyTeacher 2mo ago
        > By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something. I think he means before the official release.

kcexn 2mo ago

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.

pjmlp 2mo ago
In the countries where Engineering is a professional title and not something people decide to call themselves, we still know the difference.
- kcexn 2mo ago
  In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?
  - pjmlp 2mo ago
    In many, I am at least aware of Portugal, Germany and Canada. https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60650 https://www.lexpoint.pt/Default.aspx?PageId=128&ContentId=60... https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-ingenieurin-nennen https://www.vdi.de/news/detail/wer-darf-sich-ingenieur-oder-... https://engineerscanada.ca/become-an-engineer/use-of-professional-title-and-designations https://engineerscanada.ca/become-an-engineer/use-of-profess... You can call yourself engineer if you feel like it, however in case it comes to some court case due to liabilities and such, there might be some issues coming up with having Eng in that contract signature. Many here would probably say that they have never did the exam, and nonetheless use the title, which is as mentioned, not an issue as long as you don't land in court and the validation of title doesn't come up. Also in most European countries, being an Engineer even if not professionally qualified, automatically means that the person in question took a university degree in engineering, on an university whose engineering degree was certified as such by the government organisation responsible for all engineering professions.
    - 2mo ago

rockemsockem 2mo ago

I agree that all those pieces are important, for sure. But it can all be undercut by a few for-loops that don't consider string re-allocations. That covers the "don't understand good code in the slightest, make big mistakes" side of things, but the other side is being able to think about the algorithm that is being run in your system (sometimes across multiple layers of code) and writing code that eeks out the highest performance from the system you're on in the programming language you're using. Also, to be clear, "the algorithm" here doesn't have to be super complicated or theoretical it can be as straightforward as assembling some data structure in response to a user's query across a few different sources. That process requires being able to write good code.