I have a recurring disagreement with a programmer about code quality. He insists that all of his code is written to the highest standard (i.e. that it looks just like the examples in the coding styles textbooks), regardless of the impact this has on functionality. I, on the other hand, think it is more important that the code written meets the needs of the business - i.e. that it works efficiently, does not take too long to develop, and is reasonably maintainable.

We recently had an argument, where a specific script he has written looks great, is perfectly styled, and works exactly as the various books describe as best practice. I have an alternate version, which has been written using a so-called "anti-pattern", and which he insists is absolutely terrible code that should never be used. However, it also happens to run approximately five times as fast.

I have been trying to convince him that he needs to use this anti-pattern, even if it is "bad code", because running quickly is more important than looking nice. He disagrees, and has point blank refused to consider writing any code that does not conform to the recognized "good" style patterns, even if this means it takes longer to write and does not perform as well.

Example case: He wants to use an ORM to access the database. For one particularly complicated query, the ORM does not optimize it well, and it takes more than 4 hours to run. I inserted some raw SQL directly, and reduced the execution time to under 30 seconds. He objected - very strongly - saying that writing raw sql queries directly is bad practice, and we should always use the ORM. Now he refuses to work on that part of the program.

I have tried to explain that having a program that works well is more important than having code that looks nice, but he just says "no it's not" and carries on writing his stylish, inefficient, code, which I then sometimes have to rewrite badly before it can be used.

At the moment, we are in a bad position, because he refuses to compromise his standards, which means that everything he does has to be checked over by me and in some cases modified to be sure that it meets the needs of the business, and not just his aesthetic standards.

How can I convince him to reprioritize, and put the objectives of the business ahead of the prettyness of his code?

Edit: Stephan Kolassa suggested I include this: I am technically his manager, but we're such a small company (~10 ppl) that I also program, and so am sort of his peer at the same time, which just makes it a little more complicated, and we don't have any fixed organizational standards or conflict resolution procedures.

  • 23
    What experience level is this programmer? If it's a junior dev, it could simply be he needs to learn that the real world and the text books are different. If it's a more senior dev, it will probably be a different approach. – corsiKa Jun 2 '15 at 19:48
  • 102
    I note that you say that the worse code runs five times faster, like that's a good thing. Who cares if it runs five times faster? A script that takes 0.01 seconds to run and a script that takes 1.0 seconds to run both run in the same amount of time as far as I am concerned, but one is a hundred times faster than the other. The metric you should be using is does the script meet the documented performance requirement?, not which is faster. It could be that neither is fast enough. – Eric Lippert Jun 2 '15 at 20:11
  • 4
    Please take discussion to the linked chat room. These comments will be deleted later. – Monica Cellio Jun 2 '15 at 21:41
  • 9
    Since, I can't post the answer due to some glitch in the system, I will add it here. The other developer talks about code quality. In my experience beautiful code always produces high quality systems. In this case however, the code is not elegant at every level. The ORM fails to produce the elegant SQL code for the required problem, leading to performance issues. I suggest you explain to the developer that if he wants to be pure with his solution then he understands that the ORM has its limitations and is not the most elegant solution. If he is worried about maintainability then add unit tests – Gaurav Agarwal Jun 4 '15 at 9:48
  • 12
    And how many million dollars are you willing to spend per percentage speedup? Sure, faster is better but so is cheaper and so is more features. These things all cost money and if you're not making smart tradeoffs between them then someone is probably overspending. – Eric Lippert Jun 5 '15 at 4:21

19 Answers 19

I wouldn't try to dictate his style of coding, let him do it the way he wants. If performance is an actual documented business requirement and he fails to fulfil it call him out on that.

If he carries on failing to meet business requirements then he is failing to do his job, start giving him official verbal warnings, then written warnings and then let him go if you have to.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Elysian Fields Jun 4 '15 at 10:29
  • 8
    @user, hello. On Workplace, we look for answers that also explain why and how, this way readers understand the reasoning behind the answer and can make a more educated interpretation of why the answer is correct. Can you edit this post to include the reason why this is the best answer? Thank you! – jmort253 Jun 6 '15 at 8:06

It looks like you have a prima donna or even worse, Michel Angelo, working for you. How long has he been in the business of programming? I am asking that question because there is a huge difference between being in the business of programming and programming. Those who us have been in the trenches for any length of time can tell him that perfection can be ugly.

His code may be textbook good, but the reality is that this code has to perform and code that takes 4 hours to run versus 30 seconds - that code can hardly be described as performing. I do software engineering but from the Devops side of the House: if the code doesn't scale, that code is no good regardless of how well that code is written and documented. And resilient, maintainable code that performs poorly is no good. So far as I am concerned, either he gets what I am saying or he is gone. He has the latitude to write the code in his own style, but that code HAS to perform.

Don't tell him to go anti-pattern. Tell him what your requirement is, give him a deadline and give him the latitude to figure out how to meet it. Given how passionate he is about his code being written textbook, he has every incentive to meet your requirement while keeping his code as textbook as possible, and that's not a bad thing.

As his manager, you will have to pull rank on him and lay down the law. You are going to have to tell him that he is accountable for the performance in his code, and you are going to have to make sure that you have from the higher ups the authority to make that accountability stick. I will give an incentive to weigh down on him: as his manager, YOU will be held accountable if his code doesn't perform. Put him on the spot because if you fail to do so, the first person your top management will go after will be you.

You say that you are "technically" his manager. Well, either you are his manager or you aren't. Make up your mind (*)

If you are his manager, then he is accountable to you as you are accountable to your management. In which case, the time for making explanations that he won't listen to is over. The non-negotiable requirement is that the code has to perform, and he has to meet that requirement. That's all there is to it.

(*) I ran into a similar problem back in 1987 with an environmental engineer who wouldn't follow our best practice as laid down by yours truly. And since my title was officially equal to his, he brushed off anything I said. I set up a three-way date between him, the honcho of the department and myself where I laid out in explicit terms what the impacts of not following our process were. The honcho ordered him to comply and said a couple of words to me afterwards in private about my being heavy handed. I didn't mind the reproach - the only thing that mattered to me is that I was getting compliance and he was no longer drilling holes through the bottom of our ship. The escalation to top management wasn't pretty to behold, but it worked. Which is all that mattered to me.

  • 46
    I like the idea of turning it in to a challenge for him. No good programmer can resist a challenge. "Find A way to make this run in under 60 seconds, you can make it look as nice as you want, and follow any best practice you want as long as it runs in under 60 seconds." – Bradley Uffner Jun 2 '15 at 17:29
  • 4
    @corsiKa I would argue that there's a difference between a development challenge and an intellectual challenge. It's an intellectual challenge to avoid development challenges. The fun comes from the intellectual challenge, if you're good. It sounds like this guy is complacent in not being intellectually challenged, which actually makes him a bad programmer despite his alleged command of style and best practices. – thanby Jun 4 '15 at 11:48
  • 4
    +1 for "perfection can be ugly" - so true, especially when you're dependent on other people's imperfect software! Out of interest, was the "drilling holes through the bottom of our ship" metaphorical or literal? – psmears Jun 4 '15 at 11:59
  • 2
    @thanby we'll simply have to agree to disagree. He seems to be a bad programmer based on what we've read, but I wouldn't say his ambition to find intellectual challenges is one of them. I do not believe being good at programming requires you to enjoy it on any level. – corsiKa Jun 4 '15 at 16:24
  • 4
    Michelangelo created works that are still remembered today, what was the name of the people who wanted him to finish sooner, or use cheaper paint, less man power etc? Of course, its more likely the man in question is just a bad decorator. – Jodrell Jun 8 '15 at 7:20

As a Senior Developer, both of you are correct. It's finding the balance that you must work towards.

Firstly, from your side, your requirements should be detailed clearly. I would recommend using the behavior-driven development (BDD) approach. This allows you to detail your requirements and ensure the software meets them.

It is current best practise to follow test-driven development (TDD) practises. In this, the developer writes "just enough" code to solve the problem - by writing failing tests and making them pass. Those BDD definitions would be the starting place. Further unit tests would drop out, but once all the BDD tests are green, you can be sure the requirements are met.

Throughout this it is expected you continue a dialog - usually at the start and end of the development. This ensures both sides understand the requirements, ironing out any ambiguity. In addition, this conversation could outline the importance or value of the request.

It is important that code is clear and understandable for future development and maintenance. However a balance should be drawn between constant polishing, and delivering value.

If you, and he, haven't - I would suggest reading Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

In reference to your ORM debate - ORMs have their pros, and cons. As you have highlighted they can be slow and inefficient, when badly configured. In addition, writing inline SQL can add an extra coupling between the database and the code. Why not just call stored procedures?

There's probably as many articles on why you should, as why you shouldn't use an ORM on the web. However, a query that takes four hours to run - especially when it can be optimised to 30 seconds - is unacceptable.

As a final thought - is this your only developer? Maybe he would benefit from pair-programming with others? Maybe he just isn't suited to work in your company?

  • 16
    Guys, I know tons of people here started on Stack Overflow, but you're not there anymore. Take the technical discussions to a chat room. – Chris Hayes Jun 3 '15 at 7:25
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat. (cc @Lilienthal) – Elysian Fields Jun 3 '15 at 18:15

First of all, you are both wrong. He is wrong to insist that code looks good, and you are wrong to insist on using an anti-pattern. The appropriate way to develop software lies somewhere in the middle of your two ideologies. It is possible to follow best practices and still have code that can be developed quickly, has good performance, and is maintainable, and this is where you both need to get to.

There are many ways to do this. Your developer seems to be of the type to see "best practice" and never stray, even when the best practices change. The best way to fix that is to find a better best practice to meet your needs, and then you both must follow it.

It is important to not get stuck on the terminology, or precise methodology, and this sounds like it may be a problem for your developer. No best practice is any good if you cannot implement it, or if it results in poorly performing code. Rather than arguing with your developer, you should try to understand why he refuses to write code that does not look good, and then nudge him towards a practice that allows him to write good looking code as well as good performing code.

In case you do not believe that formatting is an issue, just Google the phrase "space or indent programming" and be amazed at all of it. How code is formatted has a lot to do with how maintainable it is in the long run. Also, check out some of these books, recommended by Jeff Atwood. They are all good, and will help you understand better why you are just as wrong as your developer is.

Ultimately, you need to stop competing with the developer. You are on opposite sides of the spectrum, and if you both just say "I am right," you will never get better. You must try to understand where he is coming from, and hopefully he will see the effort and then try to understand where you are coming from. Perhaps if you try to optimize the 4 hour query using a different "best practice" that still looks good, he will understand better.

Some links to a few development methodologies:

There are many others. Some will be good, some will be bad. Some are no longer used for a reason. Our work paid for an Agile workshop, in which we covered Agile in general, and picked a subset of those principles to implement. It has helped us in many ways, and also hindered us in a couple. It is much better than what we were doing before, but in our case the issue was all process related.

We have found that the biggest help was learning to focus on the minimum viable product. This means that we give the customer the smallest bit of functionality to meet their needs at first, and expand on it as needed. This keeps the software from getting bloated with stuff the customer never asked for.

  • 2
    Yes, on the rare occasion that I have been able to find a book or authoritative blog post describing some solution I want to implement, he is willing to do it - I think his objection is that he does not want to use any code pattern or framework unless he has seen it described elsewhere. – Benubird Jun 2 '15 at 12:33
  • 5
    The specific 4-hour query could have been optimized differently, in such a way that he would be happy using it, but that would add more than a week's work (probably two) to the development time. Given that the whole task apart from that query took less than a week, I did not think the time expense was justifiable. – Benubird Jun 2 '15 at 12:33
  • 2
    @Benubird In both cases, I say "so?" If you know how to make him see reason, you should do it. But maybe be less specific. Find an overall approach that gets him to focus more on good code quickly. Agile has a range of methodologies to help with that. And proper programming sometimes takes more time up front, and that is always justified by productivity improvements later. – Dave Johnson Jun 2 '15 at 12:52
  • 6
    "that is always justified by productivity improvements later" - please be careful about using always; I can think of plenty of exceptions to that statement. – Ypnypn Jun 3 '15 at 3:24

I have never encountered a competent person in any field who values rigid adherence to rules and forms over outcomes and function. If wrapping one's self in the flag is the first refuge of the scoundrel, then wrapping one's self in a set of rigid rules is the first refuge of the incompetent.

I would be concerned that you're stuck with a "Cargo Cult" or "cookbook" programmer i.e. one that does not understand his craft but merely mimics the examples of others.

He maybe clinging to patterns and formatting with such tenacity to disguise that he doesn't actually understand the nuances of when to use which patterns and practices. He uses moral arguments about personal and professional integrity that he claims require him to write code in the "One true way," to hide the fact that he knows no other way to write code.

I think this is pretty clear because all real statements of "best practices" always come with the caveat, "for the following circumstances or parameters." There is no such as a universal set of "best practices" that will always be the optimal choice for every project.

In particular, best practice can vary enormously between small shops such as yours and huge institutions. In smaller shops, primary requirements are speed, flexibility, execution and above all shipping. If you're small and don't ship, you die. Matters like formatting and style don't matter much because the people who maintain the code are likely going to be the ones who wrote it. Small shops do more turnkey work wherein hand tweaking performance is an important value add.

Conversely, in large institutions corporate or government, the primary requirements are often integration into larger projects combined with long term maintainability by individuals years down the road who didn't write the code. Performance often isn't as big an issue because the big guys can often just throw more hardware at the problem.

It sounds to me like your coder is fixated on "best practices" for large institutional programming instead of best practices for small company programming. Most of the books and even the formal education these days seems to focus on that market so if he actually only mimics what he has read, he may not really understand that "best practices" change with the environment.

I think you need to test him to find out exactly what kind of programmer he actually is i.e. whether he's a arrogant, jackass primo uomo with skills or an incompetent who hides behind a façade perfectionism. Order him to produce some hand optimized code like you wrote just see if he can actually do it.

If he does have the skills but simply prizes form over function, then you might be able to bring him around to the awareness that there is no such thing as universal "best practices" and definitely no such thing as universal "best formatting."

But I'm betting you'll find out he lacks the skills. At best, he's a cookbook programmer and not a cowboy hacker who can work without structure and rules if he has to (even if he doesn't like to.) I'm betting you'll need to let him go.

  • 4
    Wish I could upvote this about 20 times. I see too many people who view whatever methodology they happened to learn in school as the One True Way - though perhaps I shouldn't complain, as it makes me look good when I wring a couple of orders of magnitude performance improvement out of their code :-) – jamesqf Jun 2 '15 at 19:01
  • +1'd. Though I did actually encounter quite a few people that were competent and completely business-blind at the same time. How competent they were in practice depended by far the most on the manager / team leader - learn to use his strengths and limit his weaknesses. That's a big part of being a leader. Of course, he could also just be a schmuck - but that's really not something the OP can decide on his own. But in the end, your goal is best value for company and the customer - that usually means some measure of compromise between good maintainability and performance / implementation speed. – Luaan Jun 3 '15 at 14:31
  • 9
    +1 for "He maybe clinging to patterns and formatting with such tenacity to disguise that he doesn't actually understand the nuances of when to use which patterns and practices." There is no such thing as one "best practice." The best technologies and coding patterns vary dramatically between different problems. Use the best tool for the job; don't change the job to fit the tool. This is the key that the OP needs to get his programmer to understand. There are times when a 10,000x speedup doesn't matter and there are times that a 1% speedup matters a lot. Good engineers know the difference – reirab Jun 3 '15 at 19:38
  • 1
    @Luaan - I'm not sure that "business blindness" is what we are talking about here. In my experience, there is little to know correlation between programming skill and flexibility and management/business-organization. They're really different skill set. In fact, having programmers as managers is a relatively new development. In the early 90s, most people who managed programmers themselves had no coding experience because there weren't enough people gone through the pipe yet. I don't think this person is blind to business, he's blind to programming or at least has tunnel vision. – TechZen Jun 5 '15 at 22:02
  • 2
    @WayneWerner - I made a comment to one of my professors in college that it seemed like, "no matter what you do, it's a trade off." In my youth idealism, I didn't think that should be so but my professor said, "yep, that second law of thermodynamics is a b*tch." He was correct. It does eventually boil down to actual physics of the 2nd law.If you put energy toward one feature or whatever, you have to steal it from another. There's no free lunch – TechZen Jun 5 '15 at 22:05

How to explain business priorities to a programmer?

You don't, at least not to this programmer who doesn't want to hear it. He's not a manager, and apparently doesn't want to be empowered to make decisions or take action without direction to improve the business.

He wants input in the form of feature requests, and he wants to provide output in the form of perfect code.

Your desire to train him to be a decision maker, or to care about the business, isn't a bad desire, but in this case you should set that desire aside, and focus on the business priorities - making this programmer productive.

When you have a system that isn't working, you can open it up and tinker with the internals, or you can fiddle with the input until it produces the right output.

In this case I suggest you fiddle with the input to the programmer, rather than trying to change the programmer.

I have a recurring disagreement with a programmer about code quality.

Stop arguing about it.

Short and sweet:

  • Don't let him drive the conversation and make it about "code quality".
  • Don't tell him he's doing it wrong, or wasting time.
  • Don't believe that he's acting unprofessionally, even when it's clear to you that he is.
  • Accept his, "That's not my job" explanation and communicate REQUIREMENTS to him.
  • All future task requests now need to be made in writing (email is fine) with a follow up discussion.
  • All task requests have hard, objective limits on time he can spend on the task, and how performant the task must be.

Therefore the next time you communicate a task to him, do it in a way similar to the following:

Description:

We need feature X implemented, tested, and deployed by Friday, June 3rd.

Requirements:

  • Must include a test case that catches out of bounds, and correct operation.
  • Must not take more than 180 seconds to execute on production database SOME_DATABASE
  • Must pass LINT/etc testing for company coding standards.

Then during the discussion find out if he has any issues with the requirements. If he does, then you do the task or re-work the requirements to fit his capabilities. Take the hard work away from him and handle it yourself - there should be a clear delineation between your work and his. When he fails, don't try to "fix" him - figure out why he didn't meet your expectations, and design a requirement that will help communicate your expectations to him for the next similar task.

At this point I hope you understand that your current path of trying to get him to change to fit your needs isn't going to work. You need to understand his capabilities, and then only assign him the work that he is capable of. If you get to a point where he no longer meets your needs, then you'd better dismiss him - if the business relationship between his benefits and his output no longer makes sense to you, then sever it and find someone else to fulfill his role. Not necessarily in that order.

At this point I'd usually make some conciliatory noises about how people should be able to change and constantly upgrade their skills, but right now you just need to focus on understanding your own requirements, and then communicate them to him clearly. Once you've figured out communication then you can move on to helping him improve his skills so that he can write an ORM query that runs in good time. Until then, communicate, communicate, communicate, and accept that there are some tasks you'll simply have to do yourself.

  • +1 It's so common for folks to mix up requirements and solutions, especially when they're wearing two hats. There is very rarely an absolute and singular correct solution, so arguing about which implementation is better is counterproductive if the requirements aren't clear, measurable, and documented. – ColleenV Aug 24 '15 at 19:21

This is more about code practices than business priorities.

I am a programmer and a bit set in my ways but this programmer is off the grid. I don't get why anyone would take style over speed. ORM are convenient but not efficient. It is not bad style to use SQL. It is not bad style to denormalize a database for performance. Premature optimization is a bad code practice but optimize bottlenecks is a good code practice. I will review any query that takes over 2 seconds.

My pet peeve is custom controls. The business will ask for a very specific look and I will responde but the standard control presents the information. Standard controls are fast and tested. When we upgrade we don't need to coordinate multiple libraries.

Why would any programmer want to use a ORM that takes 4 hours to run? It would take 4 hours to test. If the programmer was fighting to go SQL to shave 4 seconds off an 8 second query and the business said 8 seconds is good enough we want to stay ORM for maintainability then I would get that debate.

As for how to convince the programmer? I would call it more a code practices issue than business priorities. A business does not need justify that a 30 second search is better than a 4 hour search. I only do ORM because writing raw SQL is a bad practice is just plain not an acceptable. If the language and the platform supports raw SQL then it is acceptable. The programmer needs to be put on a corrective action program and HR needs to be involved. If you are not his boss then go to his boss.

  • 7
    I fully agree. I am a senior developer and it is very, very important to tailor the technology to fit the problem, not the other way around...! – Jane S Jun 2 '15 at 11:27
  • 1
    It is a worst practice not to write SQL when the situation calls for it. He is too ignorant to know that. No one should be allowed to touch an ORM without a thorough background in writing SQL code because if you don't understand what the database needs then you are ignorant and you will cause harm to the system. Data is never a black box that you don't need to understand. The meaning of the data and how it is structured is critical to getting the correct answer. ORM in the hands of someone who knows what he is doing is a good practice, in the hands of a novice is a disaster waiting to happen,. – HLGEM Aug 24 '15 at 17:14
  • Why would any programmer want to use a ORM that takes 4 hours to run? It would take 4 hours to test. This alone gets my vote. If the programmer is defending his position by saying style saves time maintaining code, then arguments as to how efficiency can shave maintenance costs are infinitely better than any "efficiency is better than style" argument. Always present an argument in terms the other person has already conceded are important. – Lord Farquaad Jul 31 '17 at 21:00

Argue from first principles.

No client or customer really cares about "best practices". But they certainly care about quality. Most of all, they want their problem solved, and the faster, easier, and cheaper, the better. (They also want to save time, money and effort in the long run, which is a big part of "quality".)

Yes, some clients/customers use "best practices" as a proxy for quality, efficiency, and so on. But only because their primary interests are quality, efficiency, etc.

So anyone offering a service (even a programmer offering services to a business) should evaluate their work with questions like "is it high quality?", "is it delivered quickly?", "does it do what the client wants?", "does it save time/money/resources in the long term?"

These are difficult questions to answer. It is much easier to answer questions like "do I follow the coding conventions?", "do I implement the spec correctly?", and "do I have a Javadoc description for each method?" Such questions are an easy way to avoid the tough questions. But a good programmer does ask the tough questions of his/her code.

Best practices are important. They assist with creating quality products that save time/money/resources in the long run. They are particularly useful when you are trying to make a decision and have little hard evidence about which alternative is better. But when you do have clear information about an alternative (e.g. it would take 10 minutes instead of 4 hours, with very little chance of creating problems later on) then common sense trumps best practice!

If your programmer thinks a piece of code is "terrible and should never be used", ask him to justify this from first principles (rather than best practices). Does it have a bug? Is there a risk it contains a security vulnerability? Is it likely to add a lot of time to maintenance or new features down the track? Will it confuse other programmers? And are the problems with it actually worth the time spent implementing a "better" alternative? Make sure you listen to what he says. If he makes a strong argument, don't let your ego overrule.

A note on integrity and habit

Good habits are valuable. If your developers are constantly practising and refining their ability to write clear, clean, well-documented code, they will get efficient at it and will be less tempted to be lazy and cut corners. This is great for the quality of your codebase!

Your programmer clearly has integrity. Don't try to kill it—use it! Give him tasks where quality is important. E.g. ask him to clean up messy code written by someone else that is becoming hard to maintain. Ask him to implement functionality where it's important for the code to be maintainable.

He insists that all of his code is written to the highest standard (i.e. that it looks just like the examples in the coding styles textbooks), regardless of the impact this has on functionality. I, on the other hand, think it is more important that the code written meets the needs of the business - i.e. that it works efficiently, does not take too long to develop, and is reasonably maintainable.

You realize you both have the same goal, right?

Best practices are such for a reason. They exist to keep code well organized and separated so that it works efficiently, does not take too long to develop, and is reasonably maintainable.

Sure, your developer might benefit from a dash of pragmatism, or a better understanding of when the rules can be bent safely. But it also sounds as though you might benefit from a longer term view of how the quality of the codebase aids your business goals.

Your question is about how to explain business priorities to the programmer, but it sounds as though you've done that. What you haven't done is listen to the business priorities of your programmer. You two will need to compromise. There are many more solutions to the problem than "use direct SQL" and "use the ORM". You can look to improve the ORM's performance. You can look to isolate the SQL so that it is less troublesome to the programmer.

In short, to get what you want, you need to stop arguing and start cooperating.

  • 3
    It sounds like he has given this developer plenty of chance to explain himself, and that this developer has not. Listening to and understanding your programmers is one thing, letting them dictate the application structure to a detrimental level is not acceptable – Zibbobz Jun 2 '15 at 13:37
  • 1
    @Zibbobz - how do you figure? It's pretty clear that the programmer is saying "code cleanliness is important to me". They might not be able to articulate why well, but it then falls to the manager to dig into that - they should be the skilled communicator in that role. I'm not saying to let them dictate things, but forcing them to do things your way (micromanagement) is just as bad. – Telastyn Jun 2 '15 at 13:40
  • 2
    @Telastyn - You assume that "code cleanliness is important to me" but it sounds more to me like this is the structure of code that I do and I refuse to use a different design pattern because I like the pattern that I am using. Despite the fact that the pattern the programmer is using is ineffective and inefficient for the task he has been assigned. – IDrinkandIKnowThings Jun 2 '15 at 18:13
  • 1
    @jamesqf - some internal doc isn't best practice. A general consensus of experts (like the peer reviewed answers on SE) is far closer. – Telastyn Jun 3 '15 at 18:54
  • 1
    @Telastyn: I'm assuming "best practices" here means what the OP referred to as coding style textbooks, design patterns, various buzzworded methodologies (Agile comes to mind), and the like. All claimed to be "best" by their believers, without AFAIK much in the way of objective evidence. – jamesqf Jun 3 '15 at 19:23

To be honest, I would discipline the guy, and fire him if need be. The answers already posted here have several good points regarding flexibility on approaches to problems, so I'm not going to rehash them.

It sounds like the employee you're having problems with is already at or near senior level, and understands a lot about how to code. That's not all of his job though. If you're technically his manager, he needs to listen to you regardless if he likes it or not. Obviously we haven't observed how the two of you discuss issues but it's got to be getting pretty tense. Yes, there are more than one way to solve most problems, and you should both learn to be more flexible, but several of the things you've said indicate that this person is a detriment to the company, not an asset.

Now he refuses to work on that part of the program.

Unacceptable and childish, and also a refusal to carry out a duty at your job, which as far as I'm concerned is grounds for termination.

but he just says "no it's not" and carries on writing his stylish, inefficient, code, which I then sometimes have to rewrite badly before it can be used.

Same here.

I can only imagine (and hope) that in your frustration you've embellished a bit, and I hope that as his "technically" manager you're able to hold yourself to a higher standard and not get into childish disagreements with this person. Nevertheless, if the situation is as you say it is, the employee is inflexible to a fault. You could potentially use some education and guidance with how to deal with difficult people but, at the end of the day, this employee is outright refusing to improve a product based on esoteric standards. There's only one way that this can affect your customers, and that's poorly. No matter how good this programmer might be, they're going to become a liability to the company at some point (maybe already are).

At the end of the day, you're employing them to produce a working product, not pretty code. If they can't do that, then they aren't doing their job.

Having said my piece, try to remember that it's not black and white, and it's definitely not you against them, you just have different ideas about what's right. My comments here are based on the understanding that you've tried to explain business priorities and the person doesn't seem to care, which in my mind means they're not a good fit at your company. Maybe this guy would do well at a website that teaches best practices or something.

  • Unfortunately, not an embellishment - this morning I was trying to explain this to him, and he put on his headphones and turned away while I was talking. He says (quote) "I am a programmer. I'm being paid to program, not to think about the business". The problem is, the majority of his code is very good, and we can't really afford to pay a recruiter to find someone new, or to take the several weeks it would require to train them. – Benubird Jun 2 '15 at 14:16
  • 4
    Well, you've got a tough decision to make then: that attitude is all kinds of wrong. Disciplinary actions are as likely as not to make him resent you further, which won't be good either. You'll have to decide whether you just want to deal with him, or go through the pain of finding someone new and training them. It's pretty clear what's best in the long run... Does your company use incentives? Maybe you can tie some kind of reward/punishment directly to the business's goals. – DrewJordan Jun 2 '15 at 15:04
  • 3
    @Benubird Can your company afford, in the long-run, to hold onto this obstinate programmer who refuses to listen to his boss? If not, they should start investing in recruitment now. – Zibbobz Jun 2 '15 at 18:41
  • @DrewJordan Thank you for that post. It was my instant thought when I started reading the question. after all of the answers so far, I couldn't see my impression changed. – Florian Heigl Jun 5 '15 at 7:59

You may need to find out what he considers important. "Good style" is just that, style. It needs to bend to meet business needs and he needs to know that. However, there may be an underlying fear that he is dealing with which needs to be addressed.

As a case study, I worked on a team which consistently produced software at a slower pace than the customers needed. Management was continuously angry with us. We had a good reason for the slowness. Management had set up a hostile development environment where no piece of code could be changed without an explicit command to do so from our customer. Unfortunately, we had the explicit requirement to maintain this software for decades, while few if any of our customers ever thought more than a month ahead, making it impossible to do convince them of any long term ROIs. We were given great responsibility for the software, but little to no authority to do anything about it. Our mantra was "The first working prototype shown to the customer will be your final implementation." We never did resolve this roadblock. Management never did work with us to support the program in a way commensurate with our responsibilities (we were actually ordered not to try to resolve it, because merely bringing the issue up would risk continued funding). The program ended up dying instead because nobody would address the underlying business failure.

We spent a lot of time after this, as developers, trying to figure out what exactly went wrong, and what we could possibly do next time to avoid it. One of our takeaways from this exercise was the value of having multiple ways to approach a problem. He likes a ORM style, while you save eons of computing with an SQL command or two? Make it so that both can exist side by side. Quite often the value of an approach is not obvious to the other side until long after it has been finished. Allow both styles to coexist in the wild, and find out which one survives the rigors of business. Develop a sense of harmony between approaches rather than trying to dictate the one approach to rule them all. Perhaps he does all of his primary development using his extreme style, but the final product requires the addition of hacks. He may be in a position to isolate those hacks enough so that they cannot endanger the rest of the software.

If he doesn't accept this, then he is actually in the wrong. He is not the voice of the company, he is merely an employee. His voice is part of the whole and not the center of the whole (unless you hired him to be the center). An employee who cannot flex because they hold to principles in violation of the company's needs does need to be let go. But contrariwise, developers have a viewpoint of the software which cannot be found anywhere else. The business does need to flex when the developer points to a problem that is hard for anyone else to see.

The goal is to figure out how to have the two points of view coexist long enough to explore them properly. However, that can eventually fail if one side is particularly stuck in the mud. At that point, you will need to hold a polite discussion explaining that his coding style is not the center of the world, and if it gets in the way of business, he will be given tasking which provides him less and less freedom in the approaches he is allowed to take. Alternatively, he is free to agree to give ground on things like "size of paycheck" in exchange for freedom to do his job.

I didn't want to create yet another answer suggesting iterative development, but I did want to tack it onto the end of my answer. Iterative development gives him the opportunity to explore "good style" in one iteration, and then have you apply the business thumbscrews to turn it into a useful product. You may not know a priori that a task can be done in 30 seconds. However, after the first iteration, you should have a sense of time. This sense of time should allow you to provide timing requirements in the second iteration.

If you give a business requirement for a query to take under 5 minutes, and he says it can't be done, then politely take the task away from him and do it yourself. Let him twiddle his thumbs until he starts realizing his paycheck is in jeprody.

The best answer that I have read on this subject comes from the C++ FAQ.

https://isocpp.org/wiki/faq/big-picture#biz-dominates-tech

You might not like this, but the short answer is, “No.” (With the caveat that this answer is directed to practitioners, not theoreticians.)

Mature software designers evaluate situations based on business criteria (time, money and risk) in addition to technical criteria like whether something is or is not “good OO” or “good class design.” This is a lot harder since it involves business issues (schedule, skill of the people, finding out where the company wants to go so we know where to design flexibility into the software, willingness to factor in the likelihood of future changes - changes that are likely rather than merely theoretically possible, etc.) in addition to technical issues. However it results in decisions that are a lot more likely to bring good business results.

As a developer, you have a fiduciary responsibility to your employer to invest only in ways that have a reasonable expectation for a return on that investment. If you don’t ask the business questions in addition to the technical questions, you will make decisions that have random and unpredictable business consequences.

Like it or not, what that means in practice is that you’re probably better off leaving terms like “good class design” and “good OO” undefined. In fact I believe precise, pure-technical definitions of those terms can be dangerous and can cost companies money, ultimately perhaps even costing people their jobs. That sounds bizarre, but there’s a really good reason: if these terms are defined in precise, pure-technical terms, well-meaning developers tend to ignore business considerations in their desire to fulfill these pure-technical definitions of “good.”

Any purely technical definition of “good,” such as “good OO” or “good design” or anything else that can be evaluated without regard to schedule, business objectives (so we know where to invest), expected future changes, corporate culture with respect to a willingness to invest in the future, skill levels of the team that will be doing the maintenance, etc., is dangerous. It is dangerous because it deceives programmers into thinking they are making “right” decisions when in reality they might be making decisions that have terrible consequences. Or those decisions might not have terrible business consequences, but that’s the point: when you ignore business considerations while making decisions, the business consequences will be random and somewhat unpredicatable. That’s bad.

It is a simple fact that business issues dominate technical issues, and any definition of “good” that fails to acknowledge that fact is bad.

Consider this statement:

  • As a programmer, creating reasonably efficient code is part of your job as much as being a reasonably fast typer is part of a typist's job.

Then show him an example of how his code can be drastically improved.

If he can't (or wont) join the dots between that statement and your example, you need to be rid of him. It's like having a customer services rep who refuses to use their phone because they prefer emailing customers.

  • 2
    It sounds like the OP has tried this and the programmer has rebuffed the "Improved" versions several times. – IDrinkandIKnowThings Jun 2 '15 at 13:56
  • 3
    Then part two of the answer applies: "... you need to be rid of him." – Jørgen Fogh Jun 2 '15 at 15:26

There are two separate questions really: One is that a software developer (understandably) wants to create code of the highest quality, while the business wants him to create code that offers as much functionality as possible in the same time.

There is a compromise that must be taken: At some point, excessive polishing of code doesn't provide any advantage anymore. On the other hand, if the code quality is not good enough, you will get code that produces the wrong results, or crashes, or is too slow, or cannot be maintained.

You need to convince your developers to not overdo it, and they need to convince you that not adhering to some limited standard is sometimes costly in the short term, and often costly in the long term. On the other hand, being costly in the long term can be acceptable if only by delivering in a short time the business survives long enough to worry about the long term. If you can't convince your developers to produce the right amount of quality, and it costs you money, you might need to separate. (Obviously, if someone produces low quality in eight hours, and someone else produces high quality in eight hours and cannot be made to produce low quality in six hours, you still prefer the second developer. Or if that developer is happy by creating high quality and productive, and by forcing him to abandon quality you make him unhappy and unproductive, that's no good either).

The other question: It seems your developer insists on some formal approach that is inefficient, instead of using an informal approach that is very efficient (when the inefficiency is actually a problem for the business). That I see as a serious problem. If the business has a problem that needs to be solved, then any technique that doesn't solve the problem isn't acceptable, and insisting on such a technique while knowing a different one that solves the problem, that I find not acceptable.

If necessary, the developer should feel free to add comments to the code with a rant why the technique he is using is so much worse than the other technique, but it needed to be done for efficiency. (That might actually a good idea to write the reasons down in case he is asked why he used this approach in two years time.) Nevertheless, what needs to be done needs to be done.

  • 3
    I disagree that the programmer "wants to create code of the highest quality". It's rather that he's internalized a definition of quality that adheres to abstract academic (I'd even say quasi-religious) standards, but has no relationship at all to the standards needed by his employer - that is, that the code run in practical time, and be maintainable. (Code written to some particular academic standard is sometimes less than comprehensible to people unfamiliar with those standards.) – jamesqf Jun 2 '15 at 23:23
  • One of my sayings is "best practices are not Turing complete". – Joshua Jun 5 '15 at 3:59

This is a problem with his attitude, and it needs to change.

His intentions seem noble enough - he's trying to implement code that he learned in school, that he learned is safe and sanitary to the program, and is sticking to best practice for coding. This aspect is something you want out of a programmer.

What you don't want him to feel is that he can make top-level decisions about how the application should function. He is, I assume, a junior programmer, and he has not learned to adapt to special situations yet, let alone the intricacies of your own application.

If this is a repeating incident, I suggest you have a talk with him about how best practices, though good to follow, are not always the right solution. Remind him also that you are his boss, and that you won't tolerate him rejecting your decisions or going behind your back to program 'his' way.

And on an individual level, your group should be doing code review before you commit anyway - so take that opportunity to go over his well-formatted but highly inefficient code and lay out, step by step, why it's inefficient.

If he refuses to change, assign the change to someone else, or take over yourself. Unfortunately, this might be a sign that he absolutely does not work well in groups, and you may eventually have to let him go, or find a different group that works better with his 'always-strict' coding style.

  • I've tried explaining that best practices are not always the best solution, but he's just not getting it - I must not be doing a very good job of explaining. I don't suppose you could point me to some resources that explain it, maybe better than I can? – Benubird Jun 2 '15 at 13:38
  • @Benubird I'd point you to the highest-voted answer to this question. ;) Though if you want something more specific to individual problems, there's a whole SE devoted to that sort of thing – Zibbobz Jun 2 '15 at 13:41
  • @Benubird - I would recommend that you stop trying to challenge "Best Practices" And instead suggest that he needs to find a way to apply those best practices in a way that makes business sense. – IDrinkandIKnowThings Jun 2 '15 at 13:52
  • 1
    @Zibbobz - I agree. But when you challenge a firmly held belief of someone they immediately feel the need to defend their belief and so any challenge of that belief is to be defended against and any other points tend to be ignored. So instead of challenging those beliefs directly, allow the programmer to determine on their own that there are other ways of doing things. Chances are if it is that much less efficient the programmer is misapplying the best practices anyway. – IDrinkandIKnowThings Jun 2 '15 at 13:59
  • 1
    @Zibbobz - And if the question asked were "should I get rid of this programmer" Then that would be a valid answer. The OP has asked how he can get through to the programmer. Just like the OP wants the programmer to be effective, the OP is asking how he can be more effective manager. So instead of suggesting he hit the wall in a different way, suggest he look for a way around the wall. ( your metaphor not mine) – IDrinkandIKnowThings Jun 2 '15 at 14:24

In your question you don't talk about the code working correctly. Maybe your programmer spends too much time making the code look pretty but maybe he is being thorough in his error checking. Good code has a few requirements:

  • It must work an acceptable amount of the time
    • Acceptable may mean at least 95% or never less than 100% - it's your definition
  • It must not produce side effects in other code/systems (see first point)
  • It must be maintainable
    • Well formatted code is much easier to maintain than badly formatted code
  • It must be delivered by the deadline (whenever that is and remembering that deadlines can be reset depending on the needs of the business)
  • It must be affordable
  • Probably many other points

As a manger/representative of the business as a whole you want code that is high quality, cheap and developed quickly. Unfortunately, experience has shown that you can only ever get two of those. High quality, quickly developed code is expensive. Quickly developed, cheap code is low quality. High quality, cheap code takes a long time to develop.

Some programmers will not compromise on quality (I admit I am one of those) because of the huge amount of extra time required to troubleshoot, bug fix and rewrite afterwards. I will not knowingly allow a new bug to go live.

I once worked on a huge, badly written project. The code was inherited from a third party and we had really good developers working on it. The business kept on asking for it to be better and we kept on saying "This is as good as it gets". We did eventually get the code to perform better but it took 6 months to a year to make that happen and we never had a clear idea of how to make the code run faster at the time. When we said "This is as good as it gets" what we really meant was "We have exhausted all of our current ideas".

Your programmer might be in a similar situation. He is literally doing his best and can't think of any better ways of doing things. He probably doesn't appreciate being force fed certain ideas and will automatically reject them. If he independently comes up with the same idea you both win! Being a small company means he probably doesn't get much opportunity to bounce ideas off other people or receive lateral thinking ideas from people who are not so close to the project.

Having worked on other people's code I can tell you that sometimes I have needed to spend half an hour reformatting the code before I could begin to understand it. Formatting code is essential for your programmer's efficiency, even though it might run identically.

Don't try to convince your programmer to accept "bad code". Explain why there are multiple ways of doing the same thing and just because one is "good code" it doesn't automatically make the others "bad code". You need to show him that you are on his side. You want good code too! But then define what good code is. If being performant is important then give him the challenge of making it performant! Clearly state the expected outcome. E.g. We need to run this query 1000 times an hour, meaning it must be able to be run at least once every 3.6 seconds (which is probably terrible performance!)

He has been hired to be a technical expert, not a business expert. As such his professional goals may not be what you'd like them to be. You need to explain how what he does affects the rest of the business, while also understanding how the rest of the business affects his job. I would not recommend performance managing him unless you are planning to fire him.

You could also investigate the possibility of an automatic code formatter. That way he could focus on programming and use a macro or a small utility to reformat the code the way he likes it in less than a second. With the SQL I agree with him that directly written queries are bad, but, for example in PHP, you can use PDO to execute exactly the same queries with sanitised input. This is good practice! There should be a compromise where you get the speed you want and he gets the "good code" he wants.

I would also suggest getting him to profile the code to find the bottlenecks and make them a priority for efficiency. At the end of the day if his pretty code works quickly (and he writes it quickly), you don't mind do you? You want him to see your point of view so demonstrate that you can both see and value his point of view. You will have to repair the damage done to your professional relationship and it is important that you both trust each other.

  • There is nothing inherently bad about writing SQLcode, in fact in many circumstances it is the correct hing to do. Databases prefer well-written SQl (which is often not elegant to the eye of a non-database expert) because that is what they were designed to perform best with. Badly written code especially when it is designed so that SQl injection is possible is bad, well-written SQL code is good and often necessary. The problem with an ORM is that you lose the ability to train someone how to solve the hard problems that an ORM is a bad tool for because they never learn the SQLbasics. – HLGEM Aug 24 '15 at 17:26

This can be tricky. It depends a lot on what his behavior is negatively affecting.


Program performance

A good programmer should understand the separation of interface and implementation. Requirements are the "interface" so to speak of the project, and good design

I assume you are at least partially responsible for requirements of this project. You can create a requirement for this script that it run within 6 minutes.

As long as he meets the requirement, you don't care what he's doing. (This is the implementation.)

It may help him see that from everyone else's view (who can't see his source code) his program is crappy.


Development time

This is a bit trickier. On the one hand, you could make time to completion a project "requirement", but estimating the time to complete a project is (appropriately) left up to the person building it.

This one has to do very much with his job performance. You should approach it as you would with any other problem with job performance. This probably means a serious meeting, in which you express your concerns about his ability to finish work in a timely manner, etc. No easy solutions here.

The fact that this programmer refuses to work on that component is a clear sign to me that this is a matter of responsibility for the component.

From your customer's point of view, your optimization is the right thing to do: the black box that is your program performs better, and your company as an entity is responsible for the entire box.

Inside your company, individual people are responsible for individual components, and whenever a component breaks, the blame lies with that component's maintainer.

You cannot decouple that responsibility from the decision making power.

Overriding the decision is your prerogative as a manager, but at the same time you are taking full responsibility for the decision, which includes a paper trail that documents the objections of your programmer and why they were overridden, with a copy for everyone.

Your programmer is predicting that this will have negative consequences down the line, and is trying to cover his lower backside.

  • 4
    This is not really an answer the question but a reanalysis of the problem... there has been plenty of that already. – IDrinkandIKnowThings Jun 2 '15 at 18:09
  • 2
    @ReallyTiredOfThisGame, the answer is to accept responsibility for the decision. None of the other answers are talking about that. – Simon Richter Jun 2 '15 at 19:39

Tell him that his job is NOT to write programs per se -- his jobs is to write code which adds profit for the company.

Remind him For him to be commercially viable as an employee, the code he writes must be commercially viable. If he is not able to do this, then he is a commercial liability to the company and will be treated as such. You say you are a small company so there is a chance he could bring the whole company down.

In addition you can explain that he can write programs for fun and pleasure (or to improve his skills) in his own free time, and many programmers do. But programs written on company's time need to bring profit to the company.

If he refuses to change his style (possibly to make code possibly less pretty but substantially improving performance), ask him how he would like if company would pay him is the same way: just 10% of his salary, but using really nice color-printed check. Piece of art, hand-written and hand-signed by CEO, he can hang it on the wall :-)

Yes, pragmatic solutions sometime accumulate technical debt -- ( wikipedia ) to deliver VALUE for business.

Refusing to accept technical debt is same as refusing to accept financial debt: sometimes valid solution is to borrow money to deliver product (even if later you need to pay debt).

Having less than ideally maintainable but better performing code is similar to paying for revolving credit: it allows company to stay in business.

If it takes 10 times more of his time to deliver solution, he deserves only 10% of the salary. If he fails to deliver value for business, he should be replaced with someone who does. (I am sure this will get me some downvotes, because it is straight dope and not warm and fuzzy language - oh well life is too short. And yup, downvotes are pouring in. This is why I don't contribute to this forum anymore).

  • 5
    This is not really an answer the question but a reanalysis of the problem... there has been plenty of that already. – IDrinkandIKnowThings Jun 2 '15 at 18:07
  • If you changed this to 'tell him...' It would be a good answer. He needs to know that his job is dependant on him writing commercially viable code. – Jeremy French Jun 3 '15 at 9:36
  • 1
    OP question is: how to explain business priorities to a programmer who is convinced he was hired to write nice code, disregarding performance? How my first sentence does NOT answer that question? – P.M Jun 3 '15 at 16:46
  • 1
    "This one sentence is summary what other people said with so much more words, and all what needs to be said. Case closed." -- that doesn't read as explanation to me. See Back It Up and Don't Repeat Others – gnat Jun 3 '15 at 21:13
  • 2
    Hi Peter, while you may address this in the first sentence, the OP is looking for how to deal with this situation. A one-liner telling him to do something without explaining how the OP should do so is not super useful to them - as others have stated the question is "how can I explain business priorities?" – Elysian Fields Jun 4 '15 at 10:32

protected by Elysian Fields Jun 2 '15 at 13:55

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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