This is a widespread problem that seems to most teams at some time.
Overengineering wastes precious time, does not deliver added business value, and is dangerous to the system and your career.
Any time you spend building components and elements that are not necessary is time you are taking away from more important projects. Consider two solutions to a requested feature. In one, the developer builds the simplest system he can, and it works. In another, the developer decides to add queueing, triggers, notification systems, piles of interfaces, introduces new languages, and adds all latest trendy technologies. Because there is a learning curve with each of these, it takes much longer to build. Because there many more components, the system now has many more points of failure. Because of all of the new technology, the DevOps department is very slow to set up deployment processes. Clearly, the second developer has built a Rube Goldberg nightmare machine. Overengineering has struck again.
Don’t be that guy.
The business certainly will not appreciate it.
In a related note, delivering features that are not requested by the business will often backfire. Only implement the stories requested. If you think they missed something, then talk to them about it, and make them request the additional feature. You may think adding in extras is “showing initiative” but more often than not, it upsets the business by giving them an unexpected (and perhaps unwelcome) surprise.
Believe me, the business does not like surprises.
Today's Card 