5 ms·

My perspective is that your typical business does not incentivize, or care to allow their engineers to do "proper" software engineering, which is effectively a

by proc0 2y ago

My perspective is that your typical business does not incentivize, or care to allow their engineers to do "proper" software engineering, which is effectively a proper abstraction of the requirements and its implementation from scratch (to a great extent), in order to maximize the extensibility and control of the software. Most orgs love to use some kind of existing framework or library that comes with heavy constraints on how you need to implement requirements (typically everything above the database layer). If business domains are properly abstracted, most of the time extending the software with changes is something close to adding some configuration or using existing functions with different parameters. But the hesitation to create things from scratch comes at the cost of training and also transparency, two of the highest priorities for managers and stakeholders who not only want to hire people with minimal overhead to begin contributing, but also want to understand as much as possible what the engineer is doing and how they are doing it. Software is incredibly maleable and has unlimited potential, yet somehow most places i've worked at get constantly bottle-necked by recurring problems that are very easy to solve with proper abstractions.

dylan604 2y ago
Especially in startups clawing there way to MVP release and increasing users/income. Everything is write code to solve specific need now without time to see if it can be better used/implemented. Gotta be first. If we're not first, gotta get traction to overtake first. Even knowing that and attempting to build something with best principles is still going to be a pain to maintain as it's always a moving target with no proper specs.
- fragmede 2y ago
  There's best principles and then there's over engineering. Business domains can't be properly abstracted when the business itself is in the process of being defined, so if you're the kind of software dev that craves building to a spec that won't ever change, one possibility is that a fast-moving 12-person startup just might not be your cup of tea. Nothing wrong with that, just different.
  - dylan604 2y ago
    And if you are the type that does well with band-aid code strung together with duct tape and bailing wire and even bubble gum, then don't get upset when your company gets bought and the entire code base gets rewritten into something that teams can manage
    - snowfarthing 2y ago
      I'm not entirely sure why people who "sling code" would object to their code being completely rewritten -- particularly when the startup mindset is "we'll get something working right now, and once we figure out what we're doing, we can rewrite everything into something stable." And those who don't want to participate in the "stabilization" effort typically move on to find the next shiny and exciting thing to work on.
pixl97 2y ago
Figuring out the proper abstractions is much, much harder than writing the software itself. Software changes requirements... When you do something new and useful for a customer, they will extend use of the software till it breaks again. You will always run into a new bottleneck.
- randomdata 2y ago
  The proper abstraction is that which can easily be thrown away. I've not found that to be too difficult to figure out. Maybe when I was new to development – that was too long ago to remember – but once you have experience, at least. It can become extremely difficult to figure out if you mar yourself with someone else's framework. That is quite true. But is also what the parent said.
- proc0 2y ago
  It's hard to generalize as domains vary greatly, but in general abstractions can account for more than enough extensibility unless the requirements are extremely vague and not well defined. This tends to be the case of why so many changes are constantly needed, because usually Product and Design are not defining requirements with abstractions in mind. Domain Driven Design basically aimed at tackling this issue, by trying to synchronize abstractions across departments, so I get that there are no easy solutions, especially in large orgs.
perrygeo 2y ago
Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled. It's way easier to tell your developers to sprint every two weeks in some random direction, because at least then the business has control. If they were to use the scientific method, the direction would be chosen based on experiments and empirical data that they don't understand or control. Can't have that.
- rockemsockem 2y ago
  Which proper engineering techniques are those? In general I agree with you, but the devil is in the details and a licensure body is surely the wrong way to do this.
  - perrygeo 2y ago
    Engineering (IMO) has nothing to do with licensing, and everything with how you approach the problem - Do you use gut feeling to make decisions, or do you follow the scientific method? In most so called "engineering" orgs, the scientific method is explicitly banned - decisions are made by weird scrum rituals and fabricated storypoint metrics.
    - rockemsockem 2y ago
      Agreed. I think it just comes down to most people being very bad at making decisions and doing stuff. Which, somehow, continues to amaze me given how much humanity has accomplished.
- glitchc 2y ago
  > Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled. That's not necessarily bad. The company is derisking by relying on building blocks developed by established companies with deep talent. The vast majority of projects where local developers wrote everything from scratch are nightmarish to maintain, secure and upgrade.
paulcole 2y ago
> My perspective is that your typical business does not incentivize, or care to allow their engineers to do "proper" software engineering Which fields do you think are allowed to do "proper" ________ in a typical business? If you give me the choice between working with 2 groups of people where one says, "Let's get this done the right way!" and one that says, "Let's get this done!", I'll join the second one every time.
- whstl 2y ago
  Other engineering disciplines, for one. And I'm not saying it's perfect, I'm just saying it's done properly.
  - paulcole 2y ago
    I think I’ll agree that some licensed fields (medicine, engineering) are more likely than not going to be allowed to do things the “Right Way.” But at the same time I’d bet if you asked people in those professions they’d likely say, “Our bosses don’t let us do things the proper way.” It’s more likely everybody thinks they know better than their boss regardless of the field.
    - whstl 2y ago
      I worked as an electrical engineer in the past, and there was definitely a lot of corner cutting, less-than-ideal parts, less-than-ideal suppliers, low-quality materials, and simple day-to-day things at work that just make the life of engineers bad. But that doesn't mean you throw the baby with the bathwater. I was still liable for things like fire hazard or RF interference, among other things.
  - KptMarchewa 2y ago
    Boeing practices would disagree with you.
    - whstl 2y ago
      Boeing was charged with fraud, to the tune of $2.5 billion. Crime and outliers are not a counter-example.
deleted 2y ago
[deleted]
monkeydust 2y ago
Fully agree. People are generally incentivised to solve their domain problems not to develop something that solves theirs - and potentially - problems of their adjacent team. If you can solve for this then you should be encouraging the right behaviour for abstractions which (as others have said) is a hard but worthy problem to spend time on.
glitchc 2y ago
Part of the challenge is that most developers are not engineers. In proper engineering training, there are best practices and safety guidelines taught across the board by accredited schools. In software any cowboy with a keyboard can produce code. Unsurprisingly, most of it is shite.
- whstl 2y ago
  I feel like we managed to get much closer to proper engineering in our own little corner: version control, CI/CD, code reviews, don't-write-your-own-crypto, standardization, etc. The problem is that it's still hard for software engineers to go to business people and say "no, we can't build a bridge that crosses the Atlantic Ocean". With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth.
  - glitchc 2y ago
    > With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth. It speaks again to the lack of rigor in software. In professional engineering practice, the project manager is always a P.E. who takes responsibility for the final design and signs off on the product before it goes out the door.
rustcleaner 2y ago
Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable. The problem today is competitors will iterate with piles of temporary solutions and eat your lunch while you're still designing your abstractions. If they got sued into oblivion for shipping broken crap, they wouldn't be so quick to iterate on junk! PE licensure could also foster a security culture in software like none other, as no PE is going to put his fortunes on the line to save a buck skipping formal verifications and avoiding inconvenient best practices!
- deleted 2y ago
  [deleted]
- pphysch 2y ago
  Law may be part of the solution, but overall we need a culture of demanding tailored demos. If you ask an average SaaS, "show me how this can produce value in my environment before I buy in", they may be incredulous and expose that it will take months/years of effort to get it properly integrated. OTOH there are many genuinely great products that don't require massive upfront effort to start producing value. Demanding tailored demos can help you separate the wheat from the chaff.
- mmcdermott 2y ago
  > Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable. You would almost certainly see an increase of in-house software developers and consultants where the code is never charged for, but is developed as it always has been. A few big companies like Microsoft and IBM would get certified and smaller software companies would be driven out of existence entirely. There would definitely not be a golden age of rigorous software.
- proc0 2y ago
  I would love for the U.S. to standardize software engineering like electrical engineers. It wouldn't change that much, as most companies would end up switching to "developers", but it would make it clear when a business wants some serious problem solving and not just churning out half-baked features as fast as possible.

by proc0 2y ago

dylan604 2y ago

Especially in startups clawing there way to MVP release and increasing users/income. Everything is write code to solve specific need now without time to see if it can be better used/implemented. Gotta be first. If we're not first, gotta get traction to overtake first. Even knowing that and attempting to build something with best principles is still going to be a pain to maintain as it's always a moving target with no proper specs.

fragmede 2y ago
There's best principles and then there's over engineering. Business domains can't be properly abstracted when the business itself is in the process of being defined, so if you're the kind of software dev that craves building to a spec that won't ever change, one possibility is that a fast-moving 12-person startup just might not be your cup of tea. Nothing wrong with that, just different.
- dylan604 2y ago
  And if you are the type that does well with band-aid code strung together with duct tape and bailing wire and even bubble gum, then don't get upset when your company gets bought and the entire code base gets rewritten into something that teams can manage
  - snowfarthing 2y ago
    I'm not entirely sure why people who "sling code" would object to their code being completely rewritten -- particularly when the startup mindset is "we'll get something working right now, and once we figure out what we're doing, we can rewrite everything into something stable." And those who don't want to participate in the "stabilization" effort typically move on to find the next shiny and exciting thing to work on.

pixl97 2y ago

Figuring out the proper abstractions is much, much harder than writing the software itself. Software changes requirements... When you do something new and useful for a customer, they will extend use of the software till it breaks again. You will always run into a new bottleneck.

randomdata 2y ago
The proper abstraction is that which can easily be thrown away. I've not found that to be too difficult to figure out. Maybe when I was new to development – that was too long ago to remember – but once you have experience, at least. It can become extremely difficult to figure out if you mar yourself with someone else's framework. That is quite true. But is also what the parent said.
proc0 2y ago
It's hard to generalize as domains vary greatly, but in general abstractions can account for more than enough extensibility unless the requirements are extremely vague and not well defined. This tends to be the case of why so many changes are constantly needed, because usually Product and Design are not defining requirements with abstractions in mind. Domain Driven Design basically aimed at tackling this issue, by trying to synchronize abstractions across departments, so I get that there are no easy solutions, especially in large orgs.

perrygeo 2y ago

Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled. It's way easier to tell your developers to sprint every two weeks in some random direction, because at least then the business has control. If they were to use the scientific method, the direction would be chosen based on experiments and empirical data that they don't understand or control. Can't have that.

rockemsockem 2y ago
Which proper engineering techniques are those? In general I agree with you, but the devil is in the details and a licensure body is surely the wrong way to do this.
- perrygeo 2y ago
  Engineering (IMO) has nothing to do with licensing, and everything with how you approach the problem - Do you use gut feeling to make decisions, or do you follow the scientific method? In most so called "engineering" orgs, the scientific method is explicitly banned - decisions are made by weird scrum rituals and fabricated storypoint metrics.
  - rockemsockem 2y ago
    Agreed. I think it just comes down to most people being very bad at making decisions and doing stuff. Which, somehow, continues to amaze me given how much humanity has accomplished.
glitchc 2y ago
> Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled. That's not necessarily bad. The company is derisking by relying on building blocks developed by established companies with deep talent. The vast majority of projects where local developers wrote everything from scratch are nightmarish to maintain, secure and upgrade.

paulcole 2y ago

> My perspective is that your typical business does not incentivize, or care to allow their engineers to do "proper" software engineering Which fields do you think are allowed to do "proper" ________ in a typical business? If you give me the choice between working with 2 groups of people where one says, "Let's get this done the right way!" and one that says, "Let's get this done!", I'll join the second one every time.

whstl 2y ago
Other engineering disciplines, for one. And I'm not saying it's perfect, I'm just saying it's done properly.
- paulcole 2y ago
  I think I’ll agree that some licensed fields (medicine, engineering) are more likely than not going to be allowed to do things the “Right Way.” But at the same time I’d bet if you asked people in those professions they’d likely say, “Our bosses don’t let us do things the proper way.” It’s more likely everybody thinks they know better than their boss regardless of the field.
  - whstl 2y ago
    I worked as an electrical engineer in the past, and there was definitely a lot of corner cutting, less-than-ideal parts, less-than-ideal suppliers, low-quality materials, and simple day-to-day things at work that just make the life of engineers bad. But that doesn't mean you throw the baby with the bathwater. I was still liable for things like fire hazard or RF interference, among other things.
- KptMarchewa 2y ago
  Boeing practices would disagree with you.
  - whstl 2y ago
    Boeing was charged with fraud, to the tune of $2.5 billion. Crime and outliers are not a counter-example.

deleted 2y ago

[deleted]

monkeydust 2y ago

Fully agree. People are generally incentivised to solve their domain problems not to develop something that solves theirs - and potentially - problems of their adjacent team. If you can solve for this then you should be encouraging the right behaviour for abstractions which (as others have said) is a hard but worthy problem to spend time on.

glitchc 2y ago

Part of the challenge is that most developers are not engineers. In proper engineering training, there are best practices and safety guidelines taught across the board by accredited schools. In software any cowboy with a keyboard can produce code. Unsurprisingly, most of it is shite.

whstl 2y ago
I feel like we managed to get much closer to proper engineering in our own little corner: version control, CI/CD, code reviews, don't-write-your-own-crypto, standardization, etc. The problem is that it's still hard for software engineers to go to business people and say "no, we can't build a bridge that crosses the Atlantic Ocean". With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth.
- glitchc 2y ago
  > With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth. It speaks again to the lack of rigor in software. In professional engineering practice, the project manager is always a P.E. who takes responsibility for the final design and signs off on the product before it goes out the door.

rustcleaner 2y ago

Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable. The problem today is competitors will iterate with piles of temporary solutions and eat your lunch while you're still designing your abstractions. If they got sued into oblivion for shipping broken crap, they wouldn't be so quick to iterate on junk! PE licensure could also foster a security culture in software like none other, as no PE is going to put his fortunes on the line to save a buck skipping formal verifications and avoiding inconvenient best practices!

deleted 2y ago
[deleted]
pphysch 2y ago
Law may be part of the solution, but overall we need a culture of demanding tailored demos. If you ask an average SaaS, "show me how this can produce value in my environment before I buy in", they may be incredulous and expose that it will take months/years of effort to get it properly integrated. OTOH there are many genuinely great products that don't require massive upfront effort to start producing value. Demanding tailored demos can help you separate the wheat from the chaff.
mmcdermott 2y ago
> Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable. You would almost certainly see an increase of in-house software developers and consultants where the code is never charged for, but is developed as it always has been. A few big companies like Microsoft and IBM would get certified and smaller software companies would be driven out of existence entirely. There would definitely not be a golden age of rigorous software.
proc0 2y ago
I would love for the U.S. to standardize software engineering like electrical engineers. It wouldn't change that much, as most companies would end up switching to "developers", but it would make it clear when a business wants some serious problem solving and not just churning out half-baked features as fast as possible.