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 xAn abstract factory class to create concrete instances of xWhat 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: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.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?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.
What to do when your work colleague doesn't understand the design trying to be maintained
code smell
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.