Yes and no. Building is great. I actually think that code is disposable, but products are not, at least within a healthy delta T. Code review, refactoring and the eventual full re-write is one of the most satisfying activities IMHO.
However, software suffers from badly managed customization, hard-coding, due to pressure and functionality that may not be necessarily good to all users in the system - that's what I'm referring to. =)
Well structural issues will almost always cause suffering regardless of if its software, or management/organizational. They are all systems, and antipatterns creep-in sometimes regardless of how good you may happen to be. Flexibility is what makes or breaks things.
If you can't get a good handle on the specific business requirements, or lack the power to enact necessary changes; any solution is going to be a poor approximation and potentially cause negative production value with someone.
Imo, Products are just a collection of processes that fulfill requirements. Documenting those processes and requirements is 80% of the battle, most of the issues I've run into were only issues because they weren't documented (i.e. edge-cases that are surprisingly common).
Many times, the people and processes involved don't share/get documented because they often view this implicit knowledge as job security. This often takes a really rare/gifted person with knowledge in both IT and psychology to get what you need.
Comments
That's something you should be happy about, not something that's painful. Code isn't sacrosanct, you should always be able to throw it away.
Yes and no. Building is great. I actually think that code is disposable, but products are not, at least within a healthy delta T. Code review, refactoring and the eventual full re-write is one of the most satisfying activities IMHO.
However, software suffers from badly managed customization, hard-coding, due to pressure and functionality that may not be necessarily good to all users in the system - that's what I'm referring to. =)
Well structural issues will almost always cause suffering regardless of if its software, or management/organizational. They are all systems, and antipatterns creep-in sometimes regardless of how good you may happen to be. Flexibility is what makes or breaks things.
If you can't get a good handle on the specific business requirements, or lack the power to enact necessary changes; any solution is going to be a poor approximation and potentially cause negative production value with someone.
Imo, Products are just a collection of processes that fulfill requirements. Documenting those processes and requirements is 80% of the battle, most of the issues I've run into were only issues because they weren't documented (i.e. edge-cases that are surprisingly common).
Many times, the people and processes involved don't share/get documented because they often view this implicit knowledge as job security. This often takes a really rare/gifted person with knowledge in both IT and psychology to get what you need.