I agree completely. There's a lot of pressure to know and account for every corner of a system, and it's just not possible. Even for relatively "simple" systems. I do think there are a lot of situations where leadership treats things this way (out of ignorance, ego, or otherwise). And it can be hard to navigate those situations regardless of your personal mindful approach.
One of my bosses catchphrases (there are many) is "...so we can bring this project to completion." I truly don't know what he means by that, because these projects are always a WIP even if it's just superficial maintenance. I'll have to ask them if "bring to completion" is actually a codeword for "send the client a final bill". That would make way more sense than actually thinking a project is "complete" in some true sense.
With very very few exceptions, "complete" as in not growing just means "dead" as in not used anymore. Languages like C and C++ get updated every decade or so. Protocols like HTTP and TCP/IP continue to evolve albeit much slower. Most successful software continually releases new versions, with no predetermined stopping point. (Which I actually will argue is a huge problem with our industry, and the lack of scope control results in overly complicated software.)
The only exceptions I can think of are things that are elegant because of their simplicity. The syntax of LISP or JSON are probably never going to be modified, because they are "complete" in the Dijkstra-esqe sense that there is nothing left to take away.
I am a Software Dev girl who loves Uncle Bob, is drawn to the human side of software development and clean coded applications, and enjoys acting as a liaison between the business and tech.
Ask if bring completion meant bring to an end and kill the project ;)
You guys are right. The project is never complete. It grows. People get used to good things and want even more. And sometimes what they want is not what they get so there's always some rework to do. The software requirements are hard to capture, especially that both sides use different languages (despite both speaking the same ;)). But it requires some effort on every person (party) included in a project to create an environment that everyone feels comfortable to work at.
So practice Zen and spread the Zen to everyone engaged int the project! :)
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 agree completely. There's a lot of pressure to know and account for every corner of a system, and it's just not possible. Even for relatively "simple" systems. I do think there are a lot of situations where leadership treats things this way (out of ignorance, ego, or otherwise). And it can be hard to navigate those situations regardless of your personal mindful approach.
One of my bosses catchphrases (there are many) is "...so we can bring this project to completion." I truly don't know what he means by that, because these projects are always a WIP even if it's just superficial maintenance. I'll have to ask them if "bring to completion" is actually a codeword for "send the client a final bill". That would make way more sense than actually thinking a project is "complete" in some true sense.
With very very few exceptions, "complete" as in not growing just means "dead" as in not used anymore. Languages like C and C++ get updated every decade or so. Protocols like HTTP and TCP/IP continue to evolve albeit much slower. Most successful software continually releases new versions, with no predetermined stopping point. (Which I actually will argue is a huge problem with our industry, and the lack of scope control results in overly complicated software.)
The only exceptions I can think of are things that are elegant because of their simplicity. The syntax of LISP or JSON are probably never going to be modified, because they are "complete" in the Dijkstra-esqe sense that there is nothing left to take away.
Ask if bring completion meant bring to an end and kill the project ;)
You guys are right. The project is never complete. It grows. People get used to good things and want even more. And sometimes what they want is not what they get so there's always some rework to do. The software requirements are hard to capture, especially that both sides use different languages (despite both speaking the same ;)). But it requires some effort on every person (party) included in a project to create an environment that everyone feels comfortable to work at.
So practice Zen and spread the Zen to everyone engaged int the project! :)