> An engineer that takes something simple and makes it more complex for no reason other than job security or to look smart is the worst kind of engineer.
I don't think most people set out do do this, most complexity comes from attempting to simplify things. A develop will see two similar bit's of code and try to stuff the commonality into a base class. In their minds it's simplified because there is less code but then when someone else picks up the maintenance it's more complex because now the logic is distributed. Then the requirements of each diverge slowly and over time each simple change is hacked into more code paths of this distributed logic. Eventually most simple changes take time because you have to be sure you're not breaking other potential code paths.
On a more macro scale, complicated architecture is another symptom of this over optimistic pattern matching that humans are susceptible to.
We the programmers sometimes get too caught up on extracting seemingly common code that we don't stop for a minute and think "but does it really make sense to extract it?".
It's a very classic problem and it's something that code reviews and pull requests for anything you do are such a good idea -- provided that your team is not a total echo chamber of course.
I don't think most people set out do do this, most complexity comes from attempting to simplify things. A develop will see two similar bit's of code and try to stuff the commonality into a base class. In their minds it's simplified because there is less code but then when someone else picks up the maintenance it's more complex because now the logic is distributed. Then the requirements of each diverge slowly and over time each simple change is hacked into more code paths of this distributed logic. Eventually most simple changes take time because you have to be sure you're not breaking other potential code paths.
On a more macro scale, complicated architecture is another symptom of this over optimistic pattern matching that humans are susceptible to.