
Sub parts of the Thing are described as “shared” or “reusable”… but no-one else is using them.
The Thing has lots of unit tests, but few (or no) integration tests because they are so much harder to write.
No one can explain clearly what the Thing does, because the generalised use case has obfuscated the actual problem it was originally supposed to solve.
It would be helpful to see a UML diagram of the Thing, because no one can even begin to map the dependencies in their head. Or on paper.
More time is spent worrying about elaborate corner cases than use cases.
The word “framework”.
10 replies on “6 Signs of Over-Engineering”
6 Signs of Over-Engineering http://t.co/N3vcfpK1dv
RT @catehstn: 6 Signs of Over-Engineering http://t.co/N3vcfpK1dv
RT @catehstn: 6 Signs of Over-Engineering http://t.co/N3vcfpK1dv
RT @catehstn: 6 Signs of Over-Engineering http://t.co/N3vcfpK1dv
RT @catehstn: 6 Signs of Over-Engineering http://t.co/N3vcfpK1dv
6 Signs of Over-Engineering: “the word framework” – ha http://t.co/ttrCnbieQG
So true. Seen it way too much. RT: @skemsley 6 Signs of Over-Engineering: “the word framework” – ha http://t.co/JirojswAgC
RT @skemsley: 6 Signs of Over-Engineering: “the word framework” – ha http://t.co/ttrCnbieQG
RT @skemsley: 6 Signs of Over-Engineering: “the word framework” – ha http://t.co/ttrCnbieQG
6 signs of software over-engineering – f/@catehstn – in 1 word, “a framework” – LOL good sales advice 2, for #IOT – http://t.co/Uuqw2OFfkM