5 ms·

Sorry, 99% of these buzzwords aren't applicable in real life, professional programming. Business just wants stuff to work, no matter how you make it work.

thesuperbigfrog 4y ago
>> Sorry, 99% of these buzzwords aren't applicable in real life, professional programming. Professionals use proven tools and techniques to get the job done. Design by Contract (DbC) is a proven technique that ensures code is robust and does what it is supposed to do. >> Business just wants stuff to work, no matter how you make it work. Business cares if shody code has security vulnerabilities that lets money or customer data be stolen. DbC has been proven to help prevent shody code.
vidarh 4y ago
Various forms of checking invariants is applied in all kinds of "real life, professional programming" ranging from test suites to e.g. invariants checked by your database schema. Most code contains huge amounts of manually written invariants (every check to determine if a value is valid before e.g. setting an instance variable in a class is an attempt to maintain an invariant), and often it'd be a lot faster to get stuff to work with more comprehensive ability to enforce invariants - whether just during development or in production too.
jrochkind1 4y ago
In real life, most software is a fragile unreliable timebomb waiting to ruin businesses and lives.
zabzonk 4y ago
it wants it to work correctly, and it wants it to work fast. this is what all these "buzzwords" enable.
UncleMeat 4y ago
In my experience, class invariants are among the very most useful techniques for enabling rapid development of features while managing mutable data. They allow you to "make stuff work" at a faster pace than otherwise.
nh23423fefe 4y ago
its cool that "real life" "professional" and "business" are content free buzzwords. reads like an ignorant quine
rmbyrro 4y ago
By "to work" you mean work while losing $50 million, like the stolen money mentioned in the article?
fedeb95 4y ago
Yes but also no. This kind of things, usually called "checks" in the wild, are nearly everywhere in code that works (i.e. wasn't fixed in a while and is triggered often)
wpietri 4y ago
> Business just wants stuff to work, no matter how you make it work. For sure. But from there, it's our professional responsibility to figure out good ways to make it work for as long as the business need is there. Imagine a doctor saying: "sorry, 99% of these buzzwords like 'endocrine system' aren't applicable; patients just want to feel good."
eddsh1994 4y ago
Class invariants are very useful in domain-driven development allowing you to have contracts between modules/services that can’t break the underlying business rules. You would probably like them if you spent some time reading about them and compare it to your error/exception handling logic to deal with incorrect values.
rhdunn 4y ago
If your application has any reasonably complex data, validating that data when it is being added into the system (i.e. if it meets the invariants) prevents bugs later down the line. If the data is different to what the application expects, you need to spend time identifying that data, and correcting it. If the data is complex (e.g. book metadata) it can be expensive to correct. Having up-front validation of the input (e.g. checking book subject values) prevents a whole class of errors (such as spelling errors between country names), and enforces the contract between the data and application -- the list of things validated should be based on how the application works, such as required fields/values. If there is a new value that the business need, you then know you need to make an application change in order to support that value. Some values (like the list of countries) would be an open list, and would be best stored in the database/application as a list that can be updated outside of the code changes. Some other values (esp. those that need different code/logic to function) are closed lists that should be maintained and validated in the code (e.g. as enumeration values).

thesuperbigfrog 4y ago

>> Sorry, 99% of these buzzwords aren't applicable in real life, professional programming. Professionals use proven tools and techniques to get the job done. Design by Contract (DbC) is a proven technique that ensures code is robust and does what it is supposed to do. >> Business just wants stuff to work, no matter how you make it work. Business cares if shody code has security vulnerabilities that lets money or customer data be stolen. DbC has been proven to help prevent shody code.

vidarh 4y ago

Various forms of checking invariants is applied in all kinds of "real life, professional programming" ranging from test suites to e.g. invariants checked by your database schema. Most code contains huge amounts of manually written invariants (every check to determine if a value is valid before e.g. setting an instance variable in a class is an attempt to maintain an invariant), and often it'd be a lot faster to get stuff to work with more comprehensive ability to enforce invariants - whether just during development or in production too.

jrochkind1 4y ago

In real life, most software is a fragile unreliable timebomb waiting to ruin businesses and lives.

zabzonk 4y ago

it wants it to work correctly, and it wants it to work fast. this is what all these "buzzwords" enable.

UncleMeat 4y ago

In my experience, class invariants are among the very most useful techniques for enabling rapid development of features while managing mutable data. They allow you to "make stuff work" at a faster pace than otherwise.

nh23423fefe 4y ago

its cool that "real life" "professional" and "business" are content free buzzwords. reads like an ignorant quine

rmbyrro 4y ago

By "to work" you mean work while losing $50 million, like the stolen money mentioned in the article?

fedeb95 4y ago

Yes but also no. This kind of things, usually called "checks" in the wild, are nearly everywhere in code that works (i.e. wasn't fixed in a while and is triggered often)

wpietri 4y ago

> Business just wants stuff to work, no matter how you make it work. For sure. But from there, it's our professional responsibility to figure out good ways to make it work for as long as the business need is there. Imagine a doctor saying: "sorry, 99% of these buzzwords like 'endocrine system' aren't applicable; patients just want to feel good."

eddsh1994 4y ago

Class invariants are very useful in domain-driven development allowing you to have contracts between modules/services that can’t break the underlying business rules. You would probably like them if you spent some time reading about them and compare it to your error/exception handling logic to deal with incorrect values.

rhdunn 4y ago

If your application has any reasonably complex data, validating that data when it is being added into the system (i.e. if it meets the invariants) prevents bugs later down the line. If the data is different to what the application expects, you need to spend time identifying that data, and correcting it. If the data is complex (e.g. book metadata) it can be expensive to correct. Having up-front validation of the input (e.g. checking book subject values) prevents a whole class of errors (such as spelling errors between country names), and enforces the contract between the data and application -- the list of things validated should be based on how the application works, such as required fields/values. If there is a new value that the business need, you then know you need to make an application change in order to support that value. Some values (like the list of countries) would be an open list, and would be best stored in the database/application as a list that can be updated outside of the code changes. Some other values (esp. those that need different code/logic to function) are closed lists that should be maintained and validated in the code (e.g. as enumeration values).