How to explain business priorities to a programmer?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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:

• Agile Manifesto
• Scrum
• Rapid Application Development
• Extreme Programming

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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).