Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
I respect Uncle Bob for his contributions to software engineering, but I rarely agree with him because his example scenarios and anecdotal proofs for his rules are never realistic. I find myself working on more and more projects where clear requirements do not exist because the client doesn't even know what they want. They have a vague innovative idea, and we need to make it happen. We have to think ahead and identify potential complications NOW, because if I wait a month doing the simplest thing possible, I won't have time to refactor when we realize half our architecture needs to be created anew.
Granted, not everyone works on software projects like this. But even on e-commerce websites, I have had instances where my intuition told me that my team could not trust a subcontractor at all; I had a hunch they were lying and the constant refusal to share basic details with us made me even more vigilant. It turns out they were adding service layers that did absolutely nothing except add an order of magnitude worth of latency to requests and break every other PROD build. I designed my API integration framework to generate itself based upon request and response objects and a XML mapping of endpoints to objects. My strategy allowed us to remove the subcontractor's APIs entirely and communicate directly with the client. My "overengineering" took 2 days to solve the issue.
We will never know everything in software. We aren't even aware of what we don't know most times. By following patterns and idiomatic coding styles for our environment, we end up with the best we can do while someone forces the client to provide more details.
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 respect Uncle Bob for his contributions to software engineering, but I rarely agree with him because his example scenarios and anecdotal proofs for his rules are never realistic. I find myself working on more and more projects where clear requirements do not exist because the client doesn't even know what they want. They have a vague innovative idea, and we need to make it happen. We have to think ahead and identify potential complications NOW, because if I wait a month doing the simplest thing possible, I won't have time to refactor when we realize half our architecture needs to be created anew.
Granted, not everyone works on software projects like this. But even on e-commerce websites, I have had instances where my intuition told me that my team could not trust a subcontractor at all; I had a hunch they were lying and the constant refusal to share basic details with us made me even more vigilant. It turns out they were adding service layers that did absolutely nothing except add an order of magnitude worth of latency to requests and break every other PROD build. I designed my API integration framework to generate itself based upon request and response objects and a XML mapping of endpoints to objects. My strategy allowed us to remove the subcontractor's APIs entirely and communicate directly with the client. My "overengineering" took 2 days to solve the issue.
We will never know everything in software. We aren't even aware of what we don't know most times. By following patterns and idiomatic coding styles for our environment, we end up with the best we can do while someone forces the client to provide more details.