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?

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
Earl Grey
  • 628
  • 6
  • 14
  • 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
  • http://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil – Victor Zakharov Dec 29 '16 at 14:17
  • 1
    Can you give an example where situations like in 2 or 3 might happen? – lightning_missile Dec 29 '16 at 14:21
  • 2) 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) He wrote a manager for populating static cell tableviews when we only had two screen 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. – Earl Grey Dec 29 '16 at 14:29
  • 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
  • Any optimization with non-zero opportunity cost - that is based on assumptions about future features or future performance problems. – Earl Grey Dec 29 '16 at 15:33
  • sounds like your colleague is just more cleverer than you – Ewan Dec 29 '16 at 15:37
  • 3
    Your colleague seems to be forgetting/unaware of the principle of [YAGNI](https://en.wikipedia.org/wiki/You_aren't_gonna_need_it). – Bart van Ingen Schenau Dec 29 '16 at 17:44
  • What is the development practice here? Ad hoc/get-it-done? If it's Agile/SCRUM, there shouldn't be much unexpected embellishment of the product as it would cause estimates to be off, doneness criteria likely not met, etc. – Dan1701 Dec 29 '16 at 18:12
  • What is his response to, "Now we are stuck with having to provide a type UseCase..." – JeffO Dec 30 '16 at 16:11
  • He shrugs his arms ang gives me a concerned look..and that's about it. As if it was some "vis mayor" and we have to accept it. – Earl Grey Dec 30 '16 at 21:28
  • If you have a problem with what your colleague is doing, *tell them* outright. – Miles Rout Jan 03 '17 at 23:54

1 Answers1

15

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.

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60