What to do when your work colleague doesn't understand the design trying to be maintained

Question

A software project that I am working on involves me and another programmer. The project involved an engine backend with an MVC front end. Initially I did alot of the work on the project and so setup some simple design methodologies mainly surrounding abstraction and template strategy.

For quite a while I have been off the engine backend and working on the website. However I have still maintained an interest in the engine as I was informed that I might be back on it at some point.

The project is under a very tight deadline so we are all rushing like made to get it finished on both the front end and back end.

I don't consider myself to be a great programmer and so I never try and enforce any particular design or set of methodologies on people as I'm not always sure I'm right and like to have other people offer their opinions to try and come up with better solutions. However I have noticed changes being made to this engine code that is really starting to irk me. When I confronted the developer to suggest he do the work another way he said he didn't see the point as there seemed little benefit considering the tight deadlines.

I had to try and explain that the haack he had put in could mean further development after release and I didn't think it was fair to make others pick up the slack when we could fix it now. I spent about 30mins going through what I had done and at the end of it he asked me to pretty much write the code so he could just copy it.

The basis of what was I had initialy setup was:

• An abstract class x
• An abstract factory class to create concrete instances of x

What had happened was he had put a couple of if statements that could easily have been put as virtual/abstrace methods on the abstract class and then implemented accordingly as the new change followed the same principle of other methods on the abstract class already.

This seems trivial to me, however he couldn't even grasp this even when I showed him the classes involved.

Now my question is:

1. Is this unfair to assume he should have grasped this concept. I realise that we are on tight deadlines but I thought it was trivial. The programmer is supposed to be at least an intermediate level.
2. This has happened in a number of places and I have constantly tried to get him to change but he doesn't seem to. Should I just ignore it?
3. Should I raise this issue elsewhere, or just suck it and when I'm put back on the project just go around changing all these things.

His part of the project is not going to be finished which is why I will have to go back on and help him out. I really don't want too, as he has taken a project with not great, but ok architecture and really put in alot of messy code that more than often didn't follow what was trying to be achieved.

If the question is too vague or ranty, please let me know and I'll try and edit accordingly.

EDITED: The project is expected to continue after the initial deadline as there is already follow up work planned and work that we did not fit in and has been agreed to be implemented later.

Answer 1

From supervising maybe upwards of 200 developers over the last 25 years, I reckon - the proportion of developers who are intuitively comfortable with the kind of design abstractions you are talking about - is something like a third. My approach has evolved from expecting to fix this with coaching, training and encouragement, to still working on the coaching etc. - but recognizing that this comfort has an innate quality to it, and you often can't change it. You asked if it's fair. I think the bit that isn't fair is for your management to expect a development team member to carry the responsibility for this tension and the impact of it. If you have a leader around - try explaining the tension to them in THEIR terms not yours. It's not about the other developer - it's about efficiency, future impact and risk = bottom line and therefore a clear management responsibility. Hunt for organisational solutions that exploit your relevant skills. Can you take on more design guidance work, and the other guy do more of the finishing. Don't assume all developers wouldn't want this role - many developers love being good at finishing stuff to satisfy customers fast - and are grateful for a quality design environment to be provided by someone else.

Answer 2

Sometimes its not the concept but the time taken to grok it. People don't get things when its explained to them quickly by someone, but give them time to go look for themelves and then they'll get it. Sometimes it takes a little time for thr concept to sink in.

I understand deadlines were tight, and knowledge is limited which may have had more of an impact than you'd like, but in this case (and I make assumptions here), did you point him at a factory design pattern document, or did you just expect him to understand your code by waving it under his nose shouting "you just don't get it man, you just don't get it" :)

I might even have done the same myself - shown people the code, expect them to instantly understand, get frustrated when they look blank, zoom through it in a vain attempt to make them understand, get annoyed when they just get even more confused, then either elbow them out of the way and do it myself or get told to sod off and do it myself if I'm so damn clever. Which is all an understandable reaction to my poor attempts as a teacher.

Answer 3

Abstract classes, class factories, don't get me wrong, but sounds like an artillery to kill a bird. Patterns are there to solve problems not to create them. You admitted that the project is 2 people project.

What your colleague is doing wrong, though, is that he's not following the guidelines. It will cause some mess downstream. If the project is abstracted in all ways, then he should try to follow.

Answer 4

You didn't want to force the pattern on him from the beginning, but you could have had a short discussion on some of the things you did. Under the time constraints, I doubt he'll be able to grasp your concept enough to be able to implement it as fast as his 'hack'. You want him to fix things now to prevent someone else/you from having to fix them later, but the project is not going to be done on time. Either he doesn't understand what you were doing or feels it will take too long and isn't worth risking a delay.

Let it be known when the project can be completed and raise concerns over these limitations in the future and the need for additional time. You're going to have some difficulty getting everyone to see it your way if the client is satisfied. It may not be right, but it is reality.

Answer 5

Probably not a technical issue, definetly not a programmeing problem. Sounds like nothing more than then the traditional "programming for the possible future vs meeting todays deadlines" debate, which is a specific case of "I don't like the way the other guy does his job, I want him to do it my way". Happens every day in every workplace with more than 1 staff member.

Your management and salesman skills will be more important than any technical superioirty in your design if you want to "win" this one.

I suggest reading books such as "How to win firends and influence people" and "What colour is you paracute" and other people skills books.