I've looked briefly into SPARK, because I also would prefer to avoid introducing mistakes. For now I use typed functional programming. An expressive type system along with pure functions in the money-making code (core business logic) surfaces most errors at design-time. This allows me to avoid it even being possible for data to be in a wrong state. Also property-based testing goes a long way to ensuring the logic handles unexpected inputs properly. (I mainly use standard unit tests against the logic so far. I've been meaning to get into property-based.) Outside of sensitive areas which require formal verification, for me this is enough to prevent most of the mechanical errors of software dev.
So now the problem remains (even if I used formal verification) that sometimes I do a pretty decent job of developing the wrong thing. This is usually even more wasteful than doing something mechanically wrong. This is very common when devs implement "exactly what was asked". The main mitigation is instead of implementing the requested solution, dig deeper to find out the problem that the stakeholder is having, and address that. This can be difficult (to secure stakeholder time, to communicate effectively, etc).
I've shared this before. I had a situation recently where a customer asked for "just a field" added to an entity. But when we dug a little deeper, the field by itself wasn't going to solve the problem they had. We proposed an alternative that was more work, but would directly address the problem. They were pleased with our proposal. And it turned out to be a feature that other customers also wanted. Had we added just the field, it would have become unused cruft.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Some functional languages (or subsets) can be formally proved/verified for correctness but I don't know much about that.
I love Quickcheck for property-based testing. We don't have a lot of code where it's a good fit but we have a few property-based tests in PHP. However, Quickcheck is much more powerful in a functional language. The minimum counter-example is particularly helpful in exposing errors in an easily digestible form.
Building the wrong thing is always a risk (even if you do careful requirements gathering and analysis). And if you took 5x more time to build it properly/correctly/carefully, it stings that much more when you find out that nobody needs what you built.
I've had experiences similar to yours where the customer presents his solution to the problem. And I've been burned by not digging deeper too. I've saved myself a lot of grief over the years when I started asking "what exactly are you trying to accomplish" when a customer presents a solution instead of a need/problem.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've looked briefly into SPARK, because I also would prefer to avoid introducing mistakes. For now I use typed functional programming. An expressive type system along with pure functions in the money-making code (core business logic) surfaces most errors at design-time. This allows me to avoid it even being possible for data to be in a wrong state. Also property-based testing goes a long way to ensuring the logic handles unexpected inputs properly. (I mainly use standard unit tests against the logic so far. I've been meaning to get into property-based.) Outside of sensitive areas which require formal verification, for me this is enough to prevent most of the mechanical errors of software dev.
So now the problem remains (even if I used formal verification) that sometimes I do a pretty decent job of developing the wrong thing. This is usually even more wasteful than doing something mechanically wrong. This is very common when devs implement "exactly what was asked". The main mitigation is instead of implementing the requested solution, dig deeper to find out the problem that the stakeholder is having, and address that. This can be difficult (to secure stakeholder time, to communicate effectively, etc).
I've shared this before. I had a situation recently where a customer asked for "just a field" added to an entity. But when we dug a little deeper, the field by itself wasn't going to solve the problem they had. We proposed an alternative that was more work, but would directly address the problem. They were pleased with our proposal. And it turned out to be a feature that other customers also wanted. Had we added just the field, it would have become unused cruft.
Thanks for sharing your experiences, Kasey.
Some functional languages (or subsets) can be formally proved/verified for correctness but I don't know much about that.
I love Quickcheck for property-based testing. We don't have a lot of code where it's a good fit but we have a few property-based tests in PHP. However, Quickcheck is much more powerful in a functional language. The minimum counter-example is particularly helpful in exposing errors in an easily digestible form.
Building the wrong thing is always a risk (even if you do careful requirements gathering and analysis). And if you took 5x more time to build it properly/correctly/carefully, it stings that much more when you find out that nobody needs what you built.
I've had experiences similar to yours where the customer presents his solution to the problem. And I've been burned by not digging deeper too. I've saved myself a lot of grief over the years when I started asking "what exactly are you trying to accomplish" when a customer presents a solution instead of a need/problem.