14

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 Dec 29 '16 at 14:08
  • 1
    Can you give an example where situations like in 2 or 3 might happen? – morbidCode Dec 29 '16 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. – Graham Dec 29 '16 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 Dec 29 '16 at 15:05
  • 3
    Your colleague seems to be forgetting/unaware of the principle of YAGNI. – Bart van Ingen Schenau Dec 29 '16 at 17:44
14

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, privacy policy and cookie policy

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