I am having a very difficult time because my colleague seems to exhibit

  1. Premature/Unnecessary optimization efforts
  2. Premature deduplication with questionable abstractions
    For example, we use a modified VIPER architecture. He introduced a base class for the Router component (using generics) as part of implementing the first viper stack without actually knowing what exactly will be duplicated in other routers. Now we are stuck with having to provide a type UseCase that holds use cases, but most of routers do not have multiple use cases, only one.
  3. Inventing general purpose solutions for speculative potential future features
    For example, he wrote a manager for populating static cell table views when we only had two screens like this in the app and he was not aware the design will move away from boring vertical forms to more custom UIs so the manager is useless.
  4. Opting for incidental complexity

How do I fight this when he also exhibits having a language barrier with lousy English?

  • Have you tried mandatory code reviews to give an opportunity to discuss what is going on? Have you tried white boarding with him to come up with a good solution before he sits down to start coding?
    – Becuzz
    Commented Dec 29, 2016 at 14:08
  • 1
    Can you give an example where situations like in 2 or 3 might happen? Commented Dec 29, 2016 at 14:21
  • 1
    I feel your pain, @EarlGrey. I've probably never seen a case where super up-front "generic" coding actually works out as planned in the future.
    – GHP
    Commented Dec 29, 2016 at 14:37
  • 2
    I know people who call using a quicksort instead of a bubblesort a premature optimization. What is your threshold?
    – Pieter B
    Commented Dec 29, 2016 at 15:05
  • 3
    Your colleague seems to be forgetting/unaware of the principle of YAGNI. Commented Dec 29, 2016 at 17:44

1 Answer 1


Your description sounds like the coding I did in the 1990's. To perform appropriately for the modern world is not easy. I recommend focusing on the following factors:

  • Pairing. Two sets of eyes can help guard against one persons great, but complicated implementation.
  • Code Review. Modern shops review 100% of all code changes by multiple people
  • Test Coverage. Make sure there are simple tests. Overly complicated tests can reflect overly complicated code
  • A lot of discussion about minimum viable product. Break down features into the smallest possible components. It's ok to have one ticket to change the database, another to populate reference tables and then a third to update the UI (the part that will actually be visible to the end users), but it will feel counter-intuitive as first as resistance is likely.
  • Frequent discussions on how to have smaller tickets and changes.
  • Story point voting by the whole team to open up discussions about complexity and approach.
  • Education. Make sure you have Lunch and Learns, Training sessions, etc. so that people can get exposure to good practices and why they are good.

From all the above, my main two points of focus would be code reviews and smaller stories.

At the end of the day I think the best solution for changing existing behavior is to have a dedicated person leading the change. In Agile organizations (likely the majority today), it takes a dedicated person such as the scrum-master to be constantly asking the right questions and guiding the development approach. At my last organization we had a dozen of them, one in each team to help guide folks through these kind of issues. This eliminates the need for one team member developer to be trying to convince others that 'their way is right' which can often lead to acrimonious exchanges and bad blood.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.