3 ms·

Engineering (According to Wikipedia) Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical p

Engineering (According to Wikipedia) Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems. In short engineering is the ability to follow processes and measure things. Most developers I have worked with are incapable or unwilling to measure things (on any level), therefore they are incapable or unwilling to be engineers. If you want better software set minimal, measurable, objective standards. That becomes your foundation, your law. It is as much a soft skill as a technical skill, which is explained just before halfway through the video. Software is very very bad at this and is almost entirely reliant upon compile checks to just magically set some implicit success criteria. Most developers will balk at the idea of a disciplined planned approach and just expect some abstraction to do it for them. Once you have achieved the process you test for compliance and you measure the result. Testing for compliance isn't a manual QA effort or tiny test units. Its a total process, a certification that you are willing to bet your job and credibility upon. For software such discipline is often foreign. In other jobs like medicine, law, law enforcement, soldiering, and even truck driving getting this horribly wrong will terminate your career forever and can land you in jail or result in devastating civil suits. Until software is willing to become an adult like those other professions this will remain a distant challenge and its a monumental drain on the resilience of those developers who try their best to achieve that disciplined intent.

spyke112 2y ago
Maybe it’s not the engineers that need to grow up, but the indecisive product people incapable of sticking to their principles for more than a week at a time. That statement may be a bit much, but working in organizations unable to, well, organize around ideas leads to the state we’re in today, where most developers has to run around like headless chickens and put out fires. There’s exceptions, but from my point of view they are pretty rare.
- kbolino 2y ago
  There's definitely some interplay here. I've worked with what I consider to be true software engineers. They cared about the craft, about the quality of what they produced, and about the process to get there. But that team was broken up because it worked too slowly relative to less caring developers, and stuck too closely to established tech instead of shiny new things. Some of the people remained, but they were now just software developers, writing code to deliver features and meet deadlines, now counting down the days to retirement. I've also seen quality focus conflated with architecture astronauts since both take more upfront time. When product requirements are vague, there's a tendency to design a more generalized system than strictly necessary. But not all slower speeds are for the same reason. Taking some time to think out how to meet current and immediately foreseeable needs is not the same as wasting time designing for all possibilities, but a lot of people don't seem to understand the difference. Also, sometimes you do have to go through a bit of overengineering just to learn the shape and boundaries of what you're doing.
- ryandrake 2y ago
  Yes, yes, it’s “the product people.” Or “the managers.” Anyone but ourselves. If they would just stop changing requirements, we’d stop writing awful, buggy software. Not sure I really buy it. I’ve worked in software my whole life and I have never met any software engineering team who would magically have more discipline and rigor if only the managers went away. A team that cuts corners and shortchanges testing when the clock is ticking is likely also going to do that when the deadlines are more achievable. Attention to detail, measurement, thoroughness, an obsession with correctness… these are not environment specific things that come and go. They are traits of individual developers. You either have them or you don’t, and a screaming, impatient “product guy” can’t take these things out of you. I'll admit that companies can set up processes that encourage (or discourage) rigor, and I firmly believe you can train the yolo out of software engineers. So it's not hopeless. It is very helpful to be in a company that values these things.
- austin-cheney 2y ago
  It's actually neither. Its the software leadership. Ideally the product people should know what they want and provide that in writing, because that is what they are getting (whether or not it's what they really want). The developers/engineers are responsible for building according to the requirements and constraints provided. Somebody has to own that. Ownership is important because that's where risk and failure live, and somebody ultimately must make the adult decisions that drives the product forward. Software leadership own the process definitions and risk acceptance while project managers own the budget and process operations. In software this is often tiny, so its easy to gloss over and get sloppy. Consider freeway construction though which deals with a project budget that can exceed $5-20 billion, physical inventory, hundreds of people on site providing labor, and much more. There is still engineering, product delivery, a customer, and such but the liability is greater, so the planning and ownership are more disciplined. The incentives are also greater. As a result planning and modeling become more important. Injuries and defects cost money and result in halted work, so you have to account for risks and personnel in your planning. When there is no liability and limited incentives people have no real motivation to take ownership. Other industries solve for this with some combination of licensing and broker/agent model. Licensing solves two problems. First, it sets the minimally acceptable baseline to practice and second it defines a set of ethics that become more important than employer directives.
svilen_dobrev 2y ago
Agreed. But further on the how-to-get-there: Quoting works of Phillip Armour [0], circa 2000-2003: ... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity. ... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product. ... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed. ------ so, IMO, it's the nature of Software (=knowledge) that spoils the (most) practitioneers - there's no gravity (or reality as such) there, so everything is (or seems) possible. And once you learn that "easy" way.. hard to unlearn. The software as engineering discipline needs a set of substitutes for the missing nature/reality's "laws/rules". i.e. Resiliency might be one.. All the titles of the chapters of the textbooks [1] might be candidates (correctness, maintainability/ repairability, flexibility, portability, understandability, ...). And then, depending on the domain / importance, choose smaller or bigger subset, with looser or tighter conditions. Easier to say than do it.. Most systematically-thinking people would do it implicitly - but that as well may (or will) contradict the business goals. Just thinking aloud.. [0] http://www.amazon.com/Laws-Software-Process-Production-Management/dp/0849314895/ http://www.amazon.com/Laws-Software-Process-Production-Manag... [1] https://software-engineering-book.com/ https://software-engineering-book.com/
aleph_minus_one 2y ago
> Most developers I have worked with are incapable or unwilling to measure things (on any level), therefore they are incapable or unwilling to be engineers. You should rather consider this is a sign that software development is also partly an art, and not only an engineering discipline. Also, not all (good) developers are the same: some are more "artsy" and some are more "engineeringy".
- austin-cheney 2y ago
  The elegance of software architecture is an art, the ability to organize things in a way that scales is multiple directions. The ability to practice, such as solving for data management, accessibility, security, performance, and such are disciplines that can be largely addressed by exceeding conformance to specified guidance. That is not a 100% cure, but it is certainly a greater than 80% cure. Due diligence is all that is expected. My favorite example is accessibility, because the conformance document is so well written. Accessibility can be really challenging, but the WCAG definitions are so well written with step-by-step success criteria that accessibility can be achievable by anybody. https://www.w3.org/TR/WCAG22/ https://www.w3.org/TR/WCAG22/
klysm 2y ago
> If you want better software set minimal, measurable, objective standards. That becomes your foundation, your law. This is completely intractable in practice. The things that matter cannot be readily measured. Measuring a proxy to the things that matter is fraught with peril. I’d love to see a concrete example of what you’re thinking here because in my experience it’s not possible.
- _aavaa_ 2y ago
  It is intractable in practice since there's no outside force putting pressure to do so. Actual engineering disciplines seem to manage to have such standards, and it's in part because there are real legal and monetary liabilities at stake, unlike in software.
  - klysm 2y ago
    What do you mean by such standards? What would example ones be for software?
    - fisf 2y ago
      Easy. Runtime / performance. Peak memory consumption. Correct behaviour for injected faults, latency, or invalid input. Fault free operation under simulation. The list goes on.
      - klysm 2y ago
        > Runtime / performance This is notoriously difficult to quantify even in the simplest of examples. How do you even express goals here? What if the software is targeting a variety of platforms? > peak memory consumption Is this software running on a server or a users computer? What if it’s cheaper to buy more ram? How do you even measure this accurately when garbage collectors are so prevalent and there’s performance wins from using more virtual memory? > Correct behaviour for injected faults A standard set of faults? What about combinations of faults? I can go on….
      - jraph 2y ago
jareklupinski 2y ago
> Most developers I have worked with are incapable or unwilling to measure things a quick start is setting logging level to Debug
zombot 2y ago
> a disciplined planned approach But that would not be "agile"! Programming is mostly fashion-driven and any overlap with actual engineering is completely random.

spyke112 2y ago

Maybe it’s not the engineers that need to grow up, but the indecisive product people incapable of sticking to their principles for more than a week at a time. That statement may be a bit much, but working in organizations unable to, well, organize around ideas leads to the state we’re in today, where most developers has to run around like headless chickens and put out fires. There’s exceptions, but from my point of view they are pretty rare.

kbolino 2y ago
There's definitely some interplay here. I've worked with what I consider to be true software engineers. They cared about the craft, about the quality of what they produced, and about the process to get there. But that team was broken up because it worked too slowly relative to less caring developers, and stuck too closely to established tech instead of shiny new things. Some of the people remained, but they were now just software developers, writing code to deliver features and meet deadlines, now counting down the days to retirement. I've also seen quality focus conflated with architecture astronauts since both take more upfront time. When product requirements are vague, there's a tendency to design a more generalized system than strictly necessary. But not all slower speeds are for the same reason. Taking some time to think out how to meet current and immediately foreseeable needs is not the same as wasting time designing for all possibilities, but a lot of people don't seem to understand the difference. Also, sometimes you do have to go through a bit of overengineering just to learn the shape and boundaries of what you're doing.
ryandrake 2y ago
Yes, yes, it’s “the product people.” Or “the managers.” Anyone but ourselves. If they would just stop changing requirements, we’d stop writing awful, buggy software. Not sure I really buy it. I’ve worked in software my whole life and I have never met any software engineering team who would magically have more discipline and rigor if only the managers went away. A team that cuts corners and shortchanges testing when the clock is ticking is likely also going to do that when the deadlines are more achievable. Attention to detail, measurement, thoroughness, an obsession with correctness… these are not environment specific things that come and go. They are traits of individual developers. You either have them or you don’t, and a screaming, impatient “product guy” can’t take these things out of you. I'll admit that companies can set up processes that encourage (or discourage) rigor, and I firmly believe you can train the yolo out of software engineers. So it's not hopeless. It is very helpful to be in a company that values these things.
austin-cheney 2y ago
It's actually neither. Its the software leadership. Ideally the product people should know what they want and provide that in writing, because that is what they are getting (whether or not it's what they really want). The developers/engineers are responsible for building according to the requirements and constraints provided. Somebody has to own that. Ownership is important because that's where risk and failure live, and somebody ultimately must make the adult decisions that drives the product forward. Software leadership own the process definitions and risk acceptance while project managers own the budget and process operations. In software this is often tiny, so its easy to gloss over and get sloppy. Consider freeway construction though which deals with a project budget that can exceed $5-20 billion, physical inventory, hundreds of people on site providing labor, and much more. There is still engineering, product delivery, a customer, and such but the liability is greater, so the planning and ownership are more disciplined. The incentives are also greater. As a result planning and modeling become more important. Injuries and defects cost money and result in halted work, so you have to account for risks and personnel in your planning. When there is no liability and limited incentives people have no real motivation to take ownership. Other industries solve for this with some combination of licensing and broker/agent model. Licensing solves two problems. First, it sets the minimally acceptable baseline to practice and second it defines a set of ethics that become more important than employer directives.

svilen_dobrev 2y ago

Agreed. But further on the how-to-get-there: Quoting works of Phillip Armour [0], circa 2000-2003: ... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity. ... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product. ... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed. ------ so, IMO, it's the nature of Software (=knowledge) that spoils the (most) practitioneers - there's no gravity (or reality as such) there, so everything is (or seems) possible. And once you learn that "easy" way.. hard to unlearn. The software as engineering discipline needs a set of substitutes for the missing nature/reality's "laws/rules". i.e. Resiliency might be one.. All the titles of the chapters of the textbooks [1] might be candidates (correctness, maintainability/ repairability, flexibility, portability, understandability, ...). And then, depending on the domain / importance, choose smaller or bigger subset, with looser or tighter conditions. Easier to say than do it.. Most systematically-thinking people would do it implicitly - but that as well may (or will) contradict the business goals. Just thinking aloud.. [0] http://www.amazon.com/Laws-Software-Process-Production-Management/dp/0849314895/ http://www.amazon.com/Laws-Software-Process-Production-Manag... [1] https://software-engineering-book.com/ https://software-engineering-book.com/

aleph_minus_one 2y ago

> Most developers I have worked with are incapable or unwilling to measure things (on any level), therefore they are incapable or unwilling to be engineers. You should rather consider this is a sign that software development is also partly an art, and not only an engineering discipline. Also, not all (good) developers are the same: some are more "artsy" and some are more "engineeringy".

austin-cheney 2y ago
The elegance of software architecture is an art, the ability to organize things in a way that scales is multiple directions. The ability to practice, such as solving for data management, accessibility, security, performance, and such are disciplines that can be largely addressed by exceeding conformance to specified guidance. That is not a 100% cure, but it is certainly a greater than 80% cure. Due diligence is all that is expected. My favorite example is accessibility, because the conformance document is so well written. Accessibility can be really challenging, but the WCAG definitions are so well written with step-by-step success criteria that accessibility can be achievable by anybody. https://www.w3.org/TR/WCAG22/ https://www.w3.org/TR/WCAG22/

klysm 2y ago

> If you want better software set minimal, measurable, objective standards. That becomes your foundation, your law. This is completely intractable in practice. The things that matter cannot be readily measured. Measuring a proxy to the things that matter is fraught with peril. I’d love to see a concrete example of what you’re thinking here because in my experience it’s not possible.

_aavaa_ 2y ago
It is intractable in practice since there's no outside force putting pressure to do so. Actual engineering disciplines seem to manage to have such standards, and it's in part because there are real legal and monetary liabilities at stake, unlike in software.
- klysm 2y ago
  What do you mean by such standards? What would example ones be for software?
  - fisf 2y ago
    Easy. Runtime / performance. Peak memory consumption. Correct behaviour for injected faults, latency, or invalid input. Fault free operation under simulation. The list goes on.
    - klysm 2y ago
      > Runtime / performance This is notoriously difficult to quantify even in the simplest of examples. How do you even express goals here? What if the software is targeting a variety of platforms? > peak memory consumption Is this software running on a server or a users computer? What if it’s cheaper to buy more ram? How do you even measure this accurately when garbage collectors are so prevalent and there’s performance wins from using more virtual memory? > Correct behaviour for injected faults A standard set of faults? What about combinations of faults? I can go on….
    - jraph 2y ago

jareklupinski 2y ago

> Most developers I have worked with are incapable or unwilling to measure things a quick start is setting logging level to Debug

zombot 2y ago

> a disciplined planned approach But that would not be "agile"! Programming is mostly fashion-driven and any overlap with actual engineering is completely random.