Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing that at the same time one is destroying three others.
If the subject is Software Engineering and you said "If changing and complex requirements are a problem, you are doing it wrong" the it in that sentence should be Software Engineering - but the changing and complex requirements seldomly come from the Engineers.
No, they do not come from the software engineers. It is like being a DJ who is taking requests. You are not playing music for yourself but for other people. It the DJs task to make them sound good. On the other hand, one sometimes also needs to clarify what is wanted because the customers will ask for a rock song with a slight edge of metal in it and as the DJ you will need to know what song fits that description.
It seems that when I say that requirements seldomly come from the software engineers you have somehow misunderstood me as meaning that requirements do come from the software engineers?
No, it is just that your post sounded to me like you were saying that it is a problem that the requirements are not coming from the software engineers. My post attempts to say that this is not a problem and that it actually is how it should be.
How could you possibly interpret what I wrote in that manner?
I quoted your statement "If changing and complex requirements are a problem, you are doing it wrong" and pointed out that it was not reasonable to say someone is doing Software Engineering wrong due to changing requirements, as the engineers are seldomly in charge of requirements.
Ah, now I understand what you are trying to say. Yes, the 'it' in my post is indeed referring to software engineering.
It is not so much that they are doing software engineering wrong due to changing requirements as that the changing requirements make clear that the quality of the engineering is not that great. Another engineer who is working with a higher quality perhaps could have handled the changing and complex requirements without much problems. And in another project the requirements are perhaps quite simple and there is not much requests for changes and both engineers would have done equally well because their skill was not tested much.
Of course, there also has to be some limit in changing and complex requirements beyond which it is no longer reasonable for anyone to be able to keep up...... but we do call it SOFTware as opposed to HARDware because it is supposed to be changeable.... and if that which is supposed to be changeable actually is not, there must be something wrong.....
100% agree. I realised many years ago that to try to restrict/fix requirements was futile - or, you can try, but to what end. It’s like swimming upstream.
The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).
Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).
Yes, it's indeed a property, not a problem. The problem is the accidental complexity which has the tendency to increase and requires constant effort/energy from us to keep it low.
