"Overengineering works against results"
@lupyuen
The people who had written the previous system were upset that their masterpiece could be simplified to such extent, argued (for instance) that my way had to compile code if new transitions/states were to be added, rather than editing thousands of lines of XML "code" to "declare/describe" the behavior. The equivalent Java code (per transition type) was just a couple of lines in a new Java class, was type-safe and couldn't have missing impl for transitions/states. (cont'd)
@lupyuen
The manager was "upset" because not only had my approach produced very little code for what I charged (I think it was ~100 hours for ~100 lines of Java) not understanding that writing the code had taken no time, but figuring out the solution was were the time were spent. BUT, also because this would imply that his team was too big, too many people trying to troubleshoot and understand what actually happened could be reduced down to 1-2 who fulfilled customer requests.
Big controversy.
@lupyuen
Although I agree, he forgets to define "overengineering", and reads more like "All the things I think you shouldn't do", because in reality any group of professionals will probably disagree to what extent a random piece of code is overengineered.
I was once asked to recreate a fairly complex state machine for a new framework the customer wanted to use.
Instead of doing that, I delivered a "transition machine" which simplified the problem by 1-2 magnitudes of code needed (cont'd)