8 ms·

I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of ri

I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of rigor to our work, I don't believe the title of "Software Engineer" is justified. It doesn't have to be TLA+; it doesn't have to be any particular tool or technology or pattern or whatever. But the attitude that rigor and formal technique is worth the additional effort is something that I don't find often in the current culture, or at least the narrow slice of it that I've experienced. The quote at the end sums it up nicely. Coding should be the easy part. A sentiment everyone tends to nod their head along with, but rarely has the discipline and willpower to implement.

thwy12321 8y ago
Coding is completely different from engineering, it will never be engineering, and it will never be the easy part. Engineering is a solved problem because we keep building the same buildings and the same bridges over and over. Its like deploying the same API over and over but only changing a few lines in a very rigorous way. If anything, engineering is not engineering and coding is engineering. Coding is actually creating. There is no strong hardened fool proof way to do it, theres simply too much complexity, too many possibilities for what could be.
batteryhorse 8y ago
I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Static typing imposes limitations (kind of like government), whereas dynamic typing gives you more freedom (but requires responsibility)
- eponeponepon 8y ago
  You're conflating the act of building a product with the act of writing code. Even in the most expressive of languages, there are objectively good and bad ways of instructing your hardware to perform a particular calculation or set of calculations - and in the more rigid languages there is often a flat-out right and wrong way. Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.
- darkerside 8y ago
  Parent isn't saying his way is best. He's saying it's the appropriate mindset for some types of software. What you describe might make sense for bespoke web apps (and many other applications), but it may not be appropriate for, say, firmware development, or writing a web server from scratch.
- deleted 8y ago
  [deleted]
- TeMPOraL 8y ago
  It's fine when we're talking about leisure-paced art, done by people who deeply care about what they do. But the reality of software development is different. Software is written primarily by people who treat it as a job, and care about it (on average) about as much as they're paid to - and they're being paid by people who don't care about the product, but its ability to make money. Software written in such environment is (unlike music) powering systems that affects livelihoods, health and safety of other people. With the market pushing quality down, we need a countering force pushing it up. Or, imagine dropping all regulations around planes, cars, food, health care or infrastructure. Would things be handled better by artists, free to pursue quality? Maybe. Will majority of the providers be artists, or even care about quality? No.
  - gota 8y ago
    Just a sidenote, reading your comment it occurs to me that I have no idea - and as far as I can tell never read anything about - what is the proportion of code that is done 'for fun' versus 'for pay'. If anyone has any survey or any discussion on that please reply so I can take a look at it. I'd like to confront my expectations with data
- bilg21 8y ago
  Isn't that why you have titles such as Software Engineer, Developer, Programmer? Software Engineer should have the engineering background and tackles hard problems whereas Developers and Programmers focus on products and features.
  - azhenley 8y ago
    All of these terms are used mostly interchangeably, and it just depends on what company you are at. For example, Microsoft calls them all SDEs (Software Development Engineer) and Google calls them Software Engineers.
    - pjmlp 8y ago
      In many countries it is illegal to do so unless those people are actual engineers with accredited degree by the engineers' college.
- maltalex 8y ago
  > I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Bad music carries only the risk of people not liking it. Bad code on the other hand...
  - wolco 8y ago
    Usually risks people not using it or playing your game. Rarely does it kill and in those cases (self driving cars, banking) those application usually has a company behind them.
    - munk-a 8y ago
      If the RSS reader you're building has no guarantees of working it has no value to anyone. Not all software needs to try and be bug free but all software should strive to minimize the number of bugs in it. Static typing helps to minimize bugs (when used correctly) by allowing function contract declarations and reducing the build up of defensive guards over time. I've seen code in dynamically typed languages with lines like `if (!foo is integer) raise;` which basically equate to onerous home-built static typing.
      - wolco 8y ago
        If it has no guarantee and it works it still has value for whoever uses it. If it didn't work it might have less value but still has some value. Why would guarantee free software have no value. It's like buying a used phone.. no guarantee but it still has value.
- bbeonx 8y ago
  So you're saying Python devs are all libertarians? :D <braindump> I agree that coding/development is an art, but I also am hard pressed to find anything that, when done well, isn't an art. The difference is that music doesn't have any really notion of correctness or efficiency; sure, there are ideas such as "no parallel fifths" and "tritones must resolve to M3 or m6", but this isn't an issue of correctness, but rather stylistic guidelines. Schoenberg's compositions weren't incorrect in any universal sense. Programs, on the other hand, can be incorrect or inefficient. This is because most programs have a concrete function that they produce. Dynamic types are great for exploring your solution space. I can quickly whip together a prototype, try out different solutions, etc. I don't need to design my entire program ahead of time, and this is nice. However this does not prevent me from reasoning formally about my program. Once I've muddled around a bit and built up some scaffolding, it very well may behoove me to try to shore up my design, spend some time reasoning and designing a formal algorithm/specification/etc, etc. And for the record, as a musician I definitely think formally about my compositions/pieces I'm playing. Granted, being a guitarist this usually doesn't involve me writing out my pieces with sheet music, but there is still a blend of intuition/exploration and brute computation. As an example, I often times have two disparate parts that I need to connect together, maybe by modulating, maybe by changing registers, or maybe by altering my time signature. At that point I put the guitar aside for a moment and think about my formal requirements, and then try to find some 'convincing' way to get from point A to point B. Maybe I have some constraints (I have two measures, I need to start in this position and end in that position, this finger needs to pedal this note, etc). This quickly becomes a math problem where only a small set of viable solutions exist. After 'doing the math' I am left to evaluate my solutions aesthetic quality which, I suppose, is where most people think of the 'artistic' bit comes into play. But really, I'd say artistry abounds throughout the process. And to be clear, I'm not thinking about this stuff as doing math as I'm doing it--I have my own system for thinking about this stuff that doesn't look like math. Anyway, all of this is to say that formalism can be used even in music with very real benefits. </brain-dump>
- MrEfficiency 8y ago
  I program as you say 'similar to writing music'. This is because given all of the levels of various languages, frameworks, and libraries- I'm just trying to get things to work. However, I would very much like the methodical engineering approach at my day job applied to programming. It really blows my mind we don't have full stack + auth that works cross platform out-of-the-box. It blows my mind my recent framework didnt show the post request exchange to get tokens and authenticate. There are NOT that many people that program at this level. It seems most of my programming questions are answered by asking experts rather than reading a wikipedia article. Electrical and Mechanical Engineering are better solved reading rather than asking engineers. IMO.
- emodendroket 8y ago
  But it's clear that one approach can be more correct than another. If it was supposed to save a document and instead it deletes all my documents, it's not right.
- vmchale 8y ago
  > Static typing imposes limitations (kind of like government), where to begin
- GenericsMotors 8y ago
  I hope you stick to webdevelopment and never touch anything remotely related to medical devices, or control systems.
- MaxBarraclough 8y ago
  That might work fine if you're throwing together a blogging system, but not in a critical-systems software-engineering context. When the stakes are high, it doesn't do to view your code as a creative outlet. Critical-systems software engineering is not about your creativity, it's about building maximally correct software, to minimise the probability of a catastrophic outcome. This idea that it's inherently virtuous to let software developers be creative, strikes me as quite wrong-headed. If a strict methodology produces better results (and it does), a strict methodology should be adopted. Bridge engineers don't whine about their constrained creativity. They're too busy ensuring their creations don't get anyone killed. With the curious exception of Erlang et al, few people serious about program correctness favour dynamically typed languages. There's a reason why Ada is statically typed, and strongly typed (it lacks the dangerous implicit type conversions permitted by C). An excellent article on this kind of thing: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
pron 8y ago
I think that tools such as TLA+ show their value not by convincing people that they're worth the extra effort but that they actually save you effort. The experience at Amazon and Microsoft shows exactly that, and managers were relatively easily convinced.
- im_down_w_otp 8y ago
  Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following: Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long." Me, "First of all, you should be less concerned about the length of an individual cycle and more concerned about the sum of all the cycles up to completion." Them, "Okay, but having short cycles also helps us course correct quickly, and keeps our 'velocity' up." Me, "Well, second of all, what good is it to be able to iterate really quickly toward an unspecified goal? How do you know that what you're doing will get you there? Or worse, how do you know that what you're trying to do is even possible or not? Maybe you're 'engineering' your way asymptotically toward an impossibilty result." It's sometimes crazy making to have these conversations and see how wildly distorted we've allowed our incentives and perceptions become as a group of professionals. It's become more important to produce the appearance of progress and effort than it is to actually make progress and thoughtfully apply effort.
  - dchichkov 8y ago
    The problem is, most of the people who you are working with, only have 0-2 years of experience in the technology that they are using (use of research / deep learning to build products). Look at their resumes. They'd be either recent PhD grads, who haven't built a single product in their life. Or traditional engineers who had just joined the field of building products with an approach that is very different from one that they are experienced in. I would also caution you. Do you really know the technology that you are trying to make safe? Building systems with research / deep learning is as different from traditional software development as synthetic biology from electrical engineering.
Nursie 8y ago
>the attitude that rigor and formal technique is worth the additional effort Commercially speaking - it's usually not.
- im_down_w_otp 8y ago
  Does this speak more to the pursuit of the application of software to problems generally or to the baseline triviality of problems that are funded to have software applied to them? To me it seems like an incentive problem that starts with the distorting effects of unsophisticated investors w/ unrealisitic expectations who fund following a herd mentality only things they can themselves pattern-match to.
  - Nursie 8y ago
    To me it speaks of Software being "good enough" far more easily than it can be perfect. > To me it seems like an incentive problem Why is it a problem if a buyer gets something that works well enough for a lot less time/money put in? Further to that - specifications and requirements are often imperfect, poorly pinned down, ever-changing. Software creation out in the commercial world has shifted working patterns to try to adapt to that (Agile methods amongst others). Attempting formal proof of such soft, malleable systems would appear to be a fool's errand.
    - im_down_w_otp 8y ago
      I'm not sure I follow. The challenge with this formulation of "ever-changing" is that it assumes that things like Agile methods are somehow creating the capacity to iterate toward something of value with intention and ambition in such a way that you'll achieve whatever it is that you're trying to achieve. However, what happens is that the lack of rigor in software development today seems to cause the lineage of development and associated created technology to drift further and further away from the desired commercial goal as those goals change or mutate. Creating a bunch of brittle technology and technical debt to poorly approximate Purpose-A (a purpose by the way that you might be able to formally prove trivially is actually impossible and you either shouldn't waste the money or should intentionally select the best sub-optimal solution) doesn't help you get to Purpose-B any faster. As you become aware that Purpose-B is a thing you need to angle toward, you're still dealing with the pile of bubblegum, toothpicks, and instruction manuals written in alien script that still hasn't achieved Purpose-A. It's a really weird thing to me that as an entire ecosystem and community we've decided that the most valuable way to approach software is to declare that it's impossible to ever "finish" it. If I have a series of high-assurance layers to build upon that I know I can trust, then iterating and adapting to changes actually becomes faster and easier, because I know the surface area of where a problem can actually reside and how deep in any part of a system I actually have to uproot and start over. In the current formulation of the world, basically everything is a suspect, and basically any solution is considered viable... whether it truly is or not. I've been in situations where Product Managers and Engineers spent months off and on arguing over some proposed solution or feature and never getting anywhere because everybody's basis was built on social capital, political capital, and mythology. What finally killed the conversation and allowed progress to actually happen? When a TLA+ model that invalidated one of the proposed hypotheses was presented. "Well, look. The way you want to do this is actually impossible. It will need to be done like this, this, or this instead." Seven... _seven_... sprints of about a dozen people wasted because nobody could formalize either the requirement or the approach. Until somebody did. This wasn't for a safety-critical system either.

thwy12321 8y ago

Coding is completely different from engineering, it will never be engineering, and it will never be the easy part. Engineering is a solved problem because we keep building the same buildings and the same bridges over and over. Its like deploying the same API over and over but only changing a few lines in a very rigorous way. If anything, engineering is not engineering and coding is engineering. Coding is actually creating. There is no strong hardened fool proof way to do it, theres simply too much complexity, too many possibilities for what could be.

batteryhorse 8y ago

I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Static typing imposes limitations (kind of like government), whereas dynamic typing gives you more freedom (but requires responsibility)

eponeponepon 8y ago
You're conflating the act of building a product with the act of writing code. Even in the most expressive of languages, there are objectively good and bad ways of instructing your hardware to perform a particular calculation or set of calculations - and in the more rigid languages there is often a flat-out right and wrong way. Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.
darkerside 8y ago
Parent isn't saying his way is best. He's saying it's the appropriate mindset for some types of software. What you describe might make sense for bespoke web apps (and many other applications), but it may not be appropriate for, say, firmware development, or writing a web server from scratch.
deleted 8y ago
[deleted]
TeMPOraL 8y ago
It's fine when we're talking about leisure-paced art, done by people who deeply care about what they do. But the reality of software development is different. Software is written primarily by people who treat it as a job, and care about it (on average) about as much as they're paid to - and they're being paid by people who don't care about the product, but its ability to make money. Software written in such environment is (unlike music) powering systems that affects livelihoods, health and safety of other people. With the market pushing quality down, we need a countering force pushing it up. Or, imagine dropping all regulations around planes, cars, food, health care or infrastructure. Would things be handled better by artists, free to pursue quality? Maybe. Will majority of the providers be artists, or even care about quality? No.
- gota 8y ago
  Just a sidenote, reading your comment it occurs to me that I have no idea - and as far as I can tell never read anything about - what is the proportion of code that is done 'for fun' versus 'for pay'. If anyone has any survey or any discussion on that please reply so I can take a look at it. I'd like to confront my expectations with data
bilg21 8y ago
Isn't that why you have titles such as Software Engineer, Developer, Programmer? Software Engineer should have the engineering background and tackles hard problems whereas Developers and Programmers focus on products and features.
- azhenley 8y ago
  All of these terms are used mostly interchangeably, and it just depends on what company you are at. For example, Microsoft calls them all SDEs (Software Development Engineer) and Google calls them Software Engineers.
  - pjmlp 8y ago
    In many countries it is illegal to do so unless those people are actual engineers with accredited degree by the engineers' college.
maltalex 8y ago
> I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Bad music carries only the risk of people not liking it. Bad code on the other hand...
- wolco 8y ago
  Usually risks people not using it or playing your game. Rarely does it kill and in those cases (self driving cars, banking) those application usually has a company behind them.
  - munk-a 8y ago
    If the RSS reader you're building has no guarantees of working it has no value to anyone. Not all software needs to try and be bug free but all software should strive to minimize the number of bugs in it. Static typing helps to minimize bugs (when used correctly) by allowing function contract declarations and reducing the build up of defensive guards over time. I've seen code in dynamically typed languages with lines like `if (!foo is integer) raise;` which basically equate to onerous home-built static typing.
    - wolco 8y ago
      If it has no guarantee and it works it still has value for whoever uses it. If it didn't work it might have less value but still has some value. Why would guarantee free software have no value. It's like buying a used phone.. no guarantee but it still has value.
bbeonx 8y ago
So you're saying Python devs are all libertarians? :D <braindump> I agree that coding/development is an art, but I also am hard pressed to find anything that, when done well, isn't an art. The difference is that music doesn't have any really notion of correctness or efficiency; sure, there are ideas such as "no parallel fifths" and "tritones must resolve to M3 or m6", but this isn't an issue of correctness, but rather stylistic guidelines. Schoenberg's compositions weren't incorrect in any universal sense. Programs, on the other hand, can be incorrect or inefficient. This is because most programs have a concrete function that they produce. Dynamic types are great for exploring your solution space. I can quickly whip together a prototype, try out different solutions, etc. I don't need to design my entire program ahead of time, and this is nice. However this does not prevent me from reasoning formally about my program. Once I've muddled around a bit and built up some scaffolding, it very well may behoove me to try to shore up my design, spend some time reasoning and designing a formal algorithm/specification/etc, etc. And for the record, as a musician I definitely think formally about my compositions/pieces I'm playing. Granted, being a guitarist this usually doesn't involve me writing out my pieces with sheet music, but there is still a blend of intuition/exploration and brute computation. As an example, I often times have two disparate parts that I need to connect together, maybe by modulating, maybe by changing registers, or maybe by altering my time signature. At that point I put the guitar aside for a moment and think about my formal requirements, and then try to find some 'convincing' way to get from point A to point B. Maybe I have some constraints (I have two measures, I need to start in this position and end in that position, this finger needs to pedal this note, etc). This quickly becomes a math problem where only a small set of viable solutions exist. After 'doing the math' I am left to evaluate my solutions aesthetic quality which, I suppose, is where most people think of the 'artistic' bit comes into play. But really, I'd say artistry abounds throughout the process. And to be clear, I'm not thinking about this stuff as doing math as I'm doing it--I have my own system for thinking about this stuff that doesn't look like math. Anyway, all of this is to say that formalism can be used even in music with very real benefits. </brain-dump>
MrEfficiency 8y ago
I program as you say 'similar to writing music'. This is because given all of the levels of various languages, frameworks, and libraries- I'm just trying to get things to work. However, I would very much like the methodical engineering approach at my day job applied to programming. It really blows my mind we don't have full stack + auth that works cross platform out-of-the-box. It blows my mind my recent framework didnt show the post request exchange to get tokens and authenticate. There are NOT that many people that program at this level. It seems most of my programming questions are answered by asking experts rather than reading a wikipedia article. Electrical and Mechanical Engineering are better solved reading rather than asking engineers. IMO.
emodendroket 8y ago
But it's clear that one approach can be more correct than another. If it was supposed to save a document and instead it deletes all my documents, it's not right.
vmchale 8y ago
> Static typing imposes limitations (kind of like government), where to begin
GenericsMotors 8y ago
I hope you stick to webdevelopment and never touch anything remotely related to medical devices, or control systems.
MaxBarraclough 8y ago
That might work fine if you're throwing together a blogging system, but not in a critical-systems software-engineering context. When the stakes are high, it doesn't do to view your code as a creative outlet. Critical-systems software engineering is not about your creativity, it's about building maximally correct software, to minimise the probability of a catastrophic outcome. This idea that it's inherently virtuous to let software developers be creative, strikes me as quite wrong-headed. If a strict methodology produces better results (and it does), a strict methodology should be adopted. Bridge engineers don't whine about their constrained creativity. They're too busy ensuring their creations don't get anyone killed. With the curious exception of Erlang et al, few people serious about program correctness favour dynamically typed languages. There's a reason why Ada is statically typed, and strongly typed (it lacks the dangerous implicit type conversions permitted by C). An excellent article on this kind of thing: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff

pron 8y ago

I think that tools such as TLA+ show their value not by convincing people that they're worth the extra effort but that they actually save you effort. The experience at Amazon and Microsoft shows exactly that, and managers were relatively easily convinced.

im_down_w_otp 8y ago
Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following: Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long." Me, "First of all, you should be less concerned about the length of an individual cycle and more concerned about the sum of all the cycles up to completion." Them, "Okay, but having short cycles also helps us course correct quickly, and keeps our 'velocity' up." Me, "Well, second of all, what good is it to be able to iterate really quickly toward an unspecified goal? How do you know that what you're doing will get you there? Or worse, how do you know that what you're trying to do is even possible or not? Maybe you're 'engineering' your way asymptotically toward an impossibilty result." It's sometimes crazy making to have these conversations and see how wildly distorted we've allowed our incentives and perceptions become as a group of professionals. It's become more important to produce the appearance of progress and effort than it is to actually make progress and thoughtfully apply effort.
- dchichkov 8y ago
  The problem is, most of the people who you are working with, only have 0-2 years of experience in the technology that they are using (use of research / deep learning to build products). Look at their resumes. They'd be either recent PhD grads, who haven't built a single product in their life. Or traditional engineers who had just joined the field of building products with an approach that is very different from one that they are experienced in. I would also caution you. Do you really know the technology that you are trying to make safe? Building systems with research / deep learning is as different from traditional software development as synthetic biology from electrical engineering.

Nursie 8y ago

>the attitude that rigor and formal technique is worth the additional effort Commercially speaking - it's usually not.

im_down_w_otp 8y ago
Does this speak more to the pursuit of the application of software to problems generally or to the baseline triviality of problems that are funded to have software applied to them? To me it seems like an incentive problem that starts with the distorting effects of unsophisticated investors w/ unrealisitic expectations who fund following a herd mentality only things they can themselves pattern-match to.
- Nursie 8y ago
  To me it speaks of Software being "good enough" far more easily than it can be perfect. > To me it seems like an incentive problem Why is it a problem if a buyer gets something that works well enough for a lot less time/money put in? Further to that - specifications and requirements are often imperfect, poorly pinned down, ever-changing. Software creation out in the commercial world has shifted working patterns to try to adapt to that (Agile methods amongst others). Attempting formal proof of such soft, malleable systems would appear to be a fool's errand.
  - im_down_w_otp 8y ago
    I'm not sure I follow. The challenge with this formulation of "ever-changing" is that it assumes that things like Agile methods are somehow creating the capacity to iterate toward something of value with intention and ambition in such a way that you'll achieve whatever it is that you're trying to achieve. However, what happens is that the lack of rigor in software development today seems to cause the lineage of development and associated created technology to drift further and further away from the desired commercial goal as those goals change or mutate. Creating a bunch of brittle technology and technical debt to poorly approximate Purpose-A (a purpose by the way that you might be able to formally prove trivially is actually impossible and you either shouldn't waste the money or should intentionally select the best sub-optimal solution) doesn't help you get to Purpose-B any faster. As you become aware that Purpose-B is a thing you need to angle toward, you're still dealing with the pile of bubblegum, toothpicks, and instruction manuals written in alien script that still hasn't achieved Purpose-A. It's a really weird thing to me that as an entire ecosystem and community we've decided that the most valuable way to approach software is to declare that it's impossible to ever "finish" it. If I have a series of high-assurance layers to build upon that I know I can trust, then iterating and adapting to changes actually becomes faster and easier, because I know the surface area of where a problem can actually reside and how deep in any part of a system I actually have to uproot and start over. In the current formulation of the world, basically everything is a suspect, and basically any solution is considered viable... whether it truly is or not. I've been in situations where Product Managers and Engineers spent months off and on arguing over some proposed solution or feature and never getting anywhere because everybody's basis was built on social capital, political capital, and mythology. What finally killed the conversation and allowed progress to actually happen? When a TLA+ model that invalidated one of the proposed hypotheses was presented. "Well, look. The way you want to do this is actually impossible. It will need to be done like this, this, or this instead." Seven... _seven_... sprints of about a dozen people wasted because nobody could formalize either the requirement or the approach. Until somebody did. This wasn't for a safety-critical system either.