Ask HN: How can I prove to my coworker that his code is complex?
Currently, I think the code of my coworker really complex, but for now, this is just an opinion only.
Is there any metric that will transform my opinion on a proven fact? It's a nontrivial task, I wouldn't waste too much time in trying to prove that someone's code is complex. I tried in the past with the result of being appointed as "lazy" or "basic" developer. I heard arguments like: "if you think this is complex then you are not so good" or other very unnecessary arguments. Don't prove he's writing complex code, it would be interpreted as "being wrong", but instead prove that you can come up with easier and cleaner solution. Write your own, test it and then propose it to the original author, see if he can admit that your solution is cleaner, easier to understand and easier to handle. I did this few times with very good results on feedbacks. This is the path that I eventually started to take as I progressed as a developer. Most people when shown a better way are open to it as long as it isn't presented in a manner meant to convey superiority. Yes. ...and one thing that can also happen is, when discussing a secondary solution, a third one can come up that is even better. You mean unnecessarily complex, of course. That might appear self-evident, but it is better to articulate it in situations like this. Why is it unnecessarily complex? Is it because it is handling cases which you think do not occur? Or is it implementing requirements that you think need not exist (i.e. implementing a more complex, undocumented version of the specification than the one that is actually documented?) Or is it implementing the right specification, but without an effective program design that would reduce code and process duplication, or without the effective use of existing code, of the programming language, of libraries and of tools? You need a more specific argument than "your code is too complex". No. (I don't believe cyclomatic complexity is meaningful, so it's not likely your coworker will believe it :)) The following assumes you've already politely expressed your opinion to your coworker and he's disregarded it. It's important to understand what you're proposing to do here. You want to think of it in terms of fact, but what you are actually proposing to do is start a political fight. Now, I don't know whether you're right or wrong. I also don't know whether it would be a good idea for you to start a political fight over the issue. I do know three things that are relevant to this situation, however: 1. Whether you're right and whether it's a good idea for you to start a fight are separate questions. It's important not to assume an answer to one automatically implies an answer to the other. 2. It's practically never a good idea to start a fight without carefully thinking through the costs and benefits - all of them, not just the immediate ones - and how you plan to win it. 3. In the modern environment, the usual outcome of a fight is that both parties lose. At the same time, if standing up for code quality implies a "fight" then there are several issues, only one of which is the actual code quality. CC does matter, even if in a limited sense: the more that can happen in a chunk of code, the harder it is to reason about. I guess I'd always thought that was obvious, because it's the same way with everything. Dismissing it out of hand is disingenuous. That said, metrics matter at different times, and in different ways. Sometimes things are just complex at the method level. In any case, if coworker is disregarding input, there's a systemic issue at the personal level. I hope you're just using hyperbole when you say the only course of action is a fight: that's an extreme escalation pretty early in the process. If the coworker disagrees with the opinion, why not just have a conversation about what both parties mean by "complex"? List the tradeoffs that are being made (e.g., deep vs. wide) and why making or not making them makes sense. People can discuss differences without "fighting" in any sense of the word. If they can't, they shouldn't work together, because it's stupid and a waste of time. Speaking of outcomes, what would be the outcome of "your code is too complex"? Until you define that you got nothing. There is a concept that is sometimes true, sometimes not, of the conservation of complexity. Its not just typical physics envy, sometimes it really does exist. So pushing complexity out of small pieces of code will probably make "something" more complex. So in the idea outcome, what would you make more complex, and why would that be better than status quo? Once you explore that, your plan should be pretty clear one way or another. And this is where the warfare analogy of allies comes in. If you don't know that the other guy and operations are allied because the somewhat more complex error handling code makes operations much easier, and your bosses boss has some financial interest in making life easier for ops and harder for devs, then you'll be totally surprised when the operations manager or possibly his boss, is called in as an indirect fire weapon on your position. Or possible financial crush you don't know about where you'll ship sooner or none of you will be employed for the maint time anyway. Which sucks, but the only thing worse than living in it is not knowing or understanding why. So you need to sniff out alliances. And be reasonable about giving up. There may be a perfectly rational reason you don't understand (or, maybe not...) and the best way to handle a failed campaign is to abandon it and wind it down as fast and cheaply as possible. Its possible to make horrible analogies with the military and endless distraction about politics. However, it seems fairly non-controversial as a learning tool to at least gloss over a five paragraph operations order. http://en.wikipedia.org/wiki/Five_paragraph_order I'm not sugggesting writing it all out and using NATO phonetics or making pew-pew sound effects. But failure to plan is planning to fail so if you don't at least gloss over an outline of an op order and imagine what analogy or summary you'd provide for each line, then you're not planning, so you're planning to fail. As far as SMEAC goes, ops question is asking for advice on a part of "E" but most commenters are going to complain that "S" "M" "A" and "C" are going to dramatically alter "E", so its pointless to discuss "E" in isolation. If you're allergic to the military or think "SMEAC" sounds too much like a james bond villian corporation, there are probably non-mil planning tools of equivalent usefulness that I am not as familiar with, that some should please follow up with links to... I've come up against this many times over. When it stems from over-enthusiasm for using recently discovered features or concepts I've reliably changed a trend-toward-complexity by picking a small section & re-writing it in a simpler/more elegant fashion, then proposing to the author something along the lines of "can we make it _all_ that simple"? The subtle (or not so subtle) creation of a challenge towards simplicity has worked well with coders near the beginning of their career. ^ This right here. I've come to learn that the best way to make your point in any programming debate is to go the extra mile and produce something people can see. Rhetoric and metrics are nice, but what really makes an impact is presenting an actual example of a refactoring. For the original poster: Is the original code tested? What do the tests look like? Overly complicated unit tests are an indication that things aren't well factored. If you can present a simplification of tests along with your simplified revision of code, that may really speak to how your solution is better. You're thinking about it wrong. It's not about the complexity of code or any measure thereof, but a simple communication issue. Telling someone that their code is too complex can very easily be interpreted as a personal affront, especially by more junior developers. It can very easily communicate that they are a shitty developer and don't know what they are doing. When that happens you will get nowhere. In that situation, the other person feels that they have to defend themselves. They get myopic and unable to see whatever argument you present. They simply will not accept it, or if they do they will resent you for it. The best way to go about it is to acknowledge their efforts and validate their thinking. Look at why the code is the way it is, and try and understand why it's written that way. Approach the situation not as "I am right, you are wrong" but as "I don't understand this part, can you explain it to me." When they explain and you think it's complex say something like "Ah, yes! That's what I thought it did. It seemed a bit complex so I was wondering if it did anything else. Have you considered x or y?" The more opportunities you allow to the other person to save face, and the more you value their efforts and work the further you will get. The simplest way is to provide an alternative implementation that is more correct, more succinct, and is easier to read. +1 rich hickey talk Of course that is not the least resource intensive solution.
Code reviews may help. This. You could talk all day and no one will listen. What also helps in the long run are stricter coding guidelines. When we forced stuff like early returns instead of nested ifs much of our code just got easier to follow. How did you come to the conclusion in the first place that his code is complex? The answer to this question may provide your answer to your coworker. Ultimately if its only an opinion, then you don't have much to go off... To be honest, the technical aspects raised by the question pale in comparison to the human aspects. Even from a position of authority over a coder it can be very difficult to solve the problem of "excessively complicated" code. To "solve" this from a peer position, unless your coworker is an extraordinarily humble person, is going to be quite the trick. It is likely that the cost/benefit analysis (and in engineering you are never more than a few minutes away from a cost/benefit analysis, even here in the "fuzzy human stuff" domain) is unlikely to work out in your favor with any sort of strong approach. You are unlikely to experience any positive outcomes, what ones you could are fairly minimal, and the negative outcomes (w.r.t. your employment) are almost unbounded, including the ability to outright work your way into losing your job. All you can really do is write good code yourself, keep learning how to write better code, and use this as an opportunity to learn how to deal with complicated code because goodness knows you'll never stop encountering overcomplicated code, unless this industry changes a lot. If that sounds a bit defeatist... well... it's hard to express my true feelings in text here. I've been doing this for just shy of 20 years now and have no intention of stopping, so it's not like I'm burned out or anything. Yet... you can not escape the fact that you shall always be working with people whom you wish would code better. I find it helpful to remember that A: among the set of people I really wish would code better is my past self, at times even as recently as last week and B: there are certainly plenty of other people who wish that I would code better, for their personal definition of "better". In fact, I know that even as my code tends towards the "simple" side and I find some people's overcomplicated, they consider my code oversimple. (I mean, I'm still on my side and can defend it, but, well, insert any well-known saying about opinions here, right?) A certain amount of zen and a certain amount of humility is called for here in the long term, I think. Considering the disappointing realities of human nature and office politics, I think your defeatist attitude is 100% the correct strategy. It may be worth politely and discreetly trying once to make things better, but in my experience if the individual / organization shows no interest (or just as likely, outright hostility) to the philosophy of trying to do things simply, the best recipe is to shut up, collect your paycheque, and constantly look for better opportunities elsewhere. Often times people who are good at dealing with complex code become programmers, and they themselves write complex code. Since so many projects contain a mess of complex code, programmers like these will always find jobs and you may end up with one as a coworker. It's not a bad thing but ideally they have enough of an aesthetic sense about code readability to use their powers for good. Chapter 1 of the below book is all about coupling in systems, and illustrates how coupling leads to significantly more system complexity: http://www.amazon.com/Event-Based-Programming-Taking-Events-... Get it free here: Hi all, there are some complexity KPIs that have proven to reflect the complexity of your source code. Code in nesting level N and the cyclomatic complexity (aka. McCabe complexity) [http://en.wikipedia.org/wiki/Cyclomatic_complexity] are two of them. Especially "nesting level complexity", that is the amount of code in nesting level N+ (e.g. the amount of code in nesting level 7+), is a complexity KPI that can reflect unnecessary complexity in your code. However, just having the "numbers" is not enough to convince your co-workers (I talk my own experiences here ;)). What you need is a visualization of these complexity KPIs. I used the following online-platform (https://tp.softwarediagnostics.com) to discuss issues like yours with my co-workers in an objective and transparent manner. They provide a freemium version of the platform that lets you analyze and visualize the nesting level complexity of your source code in a convenient way. Maybe it can help you in the discussion with your co-workers. (IMHO) Complex code is difficult to test so if the code can be tested easily without over using factory or tight coupled setup required then maybe the code is not so complex and maybe it's just an hard problem. Writing test can help to highlight an over complex code and an alternative code will have much simpler tests. It's not a metric but it's probably easier to agree on clean test Code is written for humans. I don't think there is any proven metric for elegance. When I was a junior dev I made a god awful complex thingamajic for basically calling a dozens of functions with different input parameters. Our lead just said "o god, not like this just call the functions " and he was correct. Unless you are in a senior/junior position trying to prove your colleague wrong will likely result of him thinking you are arrogant and will make efforts to improve things in years to come difficult. Communication usually fails. If you say "your code is too complex" despite your best efforts to be polite he might hear "I am an arrogant twat and just want to put you down for the fun of it". Some times best people lead by example. If you can write your stuff elegantly and show it to him he may appreciate the more simple approach. Or not. Unless it's an obvious antipattern like coupling of code and data we are, up to a point, discussing aesthetics. Experienced programmers often grow to appreciate simplicity if only of the categories of bugs code eliminates by just being simple. But this takes time. > I don't think there is any proven metric for elegance. there is: http://www.osnews.com/images/comics/wtfm.jpg i'm not even joking. Oh, had forgotten about that one. Actually, I think that image is posted on a wall at a floor in our office :) No one wants to hear that they are wrong, even if you proved it unless you already have their respect, or you are their boss. All programmer will hear is that "you are not doing good enough job," but the "good" is vague and graded, and lazy. Instead, show him how you would have done it. You know, as a learning opportunity. First you need to define what you mean by "complex" as that could refer to many things. A useful definition for the term will be focused on informing a decision. Why did you ask the question? Further, definitions that rely on one or many observable phenomena are more useful than definitions which rely on subjective experiences. Maybe you don't understand the problem she's solving? Or maybe the co-worker designs in a way different from your comfort zone. How about trying to learn a few new design patterns. Then that 'complex' code will become familiar. I do this by reading the code's logic aloud, and while doing so, noting the things that I have to remember to understand it. This includes things like "what was the name of that variable", "what does this function do", "has the parser read a comma", etc. Complex code results in larger "mental stacks", simple code smaller ones. This isn't really "proof", but in my experience, such a demonstration is easy to understand and leads to constructive conversations and good results. Good code should be no more complex then the problem it's solving. Though sometimes easy problems prove themselves to be complex. If you can think of a simpler way to accomplish the same task while achieving the same thing, introduce the idea. Chances are though, you don't have time to fix it, unless its young code, and you have some room in your schedule (which you don't, no one ever does). I'd just make sure the code review process is fixed so we can catch it earlier. Every developer has a different idea of what complex code means. Cyclomatic complexity is one metric, but vastly different code could have the same score. Sometimes we have to trade simplicity for flexibility, speed, or other goals. The idea that you can prove code complexity shows that you are a newer developer. I'm not sure what goal you want to achieve by proving someone else wrote complex code. There are probably better ways to achieve that goal. Readability should be paramount above complexity. Write code for future you, and future developers that will be working on the project. You might understand the complexity now, but what about after not working on it for 6 months or more. I don't know of any metric for code readability, but it should be as simple as possible. Readable code is WAY better than complex code anyday. Great programmers know this. Have you considered the possibility that you're asking the wrong question? Both watch Rich Hickey's excellent presentation on the matter and establish whether you agree on the definitions. Yes, there's a metric for that, and it's called Cyclomatic Complexity. Depending on the programming language there may or may not be tools to perform an anylisis on Cyclomatic Complexity on your code. I know for Java there are some tools. Unfortunately the OP and possibly co-worker would need to believe that the results of a CC analysis were meaningful. Also, some problems are irreducibly complex. One solution is for the OP to come up with a shorter, cleaner, better, etc. solution. Actually presenting that version to the co-worker can be interpreted as directly confrontational ... though presenting metrics instead would more likely be interpreted as a side-handed attack, rather than a direct attack. But if the OP can come up with better code, then that would answer to the OP's own satisfaction if the co-worker's code really is overly complex. Personal enlightenment (I tell this to myself) was all the OP was asking. A question I'm asking myself more often as I get older: What is the value of changing somebody's mind? To that end, rather than prove someone else's code is complex, we can emphasize the virtues of simplicity with what we do. Refactoring someone else's code in smaller increments would be the passive aggressive middle ground. There are more opportunities with code that hasn't been written yet. Maybe suggest watching this lecture as a group and then just discussing it without any additional agenda: http://www.infoq.com/presentations/Simple-Made-Easy Having worked a couple decades in the trade, occasionally with some very unstable people, I have seen one suicide. I doubt it had anything to do directly with work but it's been a reminder to be nice to people, even when they are wrong. Just merely writing what you think is a shorter, cleaner, better solution isn't really enough. It can be easy to overlook the reason for the complexity. If the rewrite seems to work as a replacement, just use it to come up with questions about the current code and ask the co-worker. If there are actual reasons for the complexity, add the necessary comments so someone else doesn't have to go through that or find out the hard way. Complexity is not a problem if something is achieved with it. That said, a complex problem will often require a complex solution and sometimes the simplest solution is the most appreciated, efficient or elegant. Poor maintainability /extensibility / modularity /scalability, bad encapsulation, abundance of side effects, spaguetti and raviolli code - among others - are perhaps the real problem you're seeing behind your coworker's complex design. It is not a war that can be easily won though, you can see how in the java ecosystem unnecessary complexity is the norm. And outside java too we see unnecessarily complex frameworks or libraries gaining heavy traction. There are all kinds of complexity metrics that exist that you could use to quantify the complexity of the code at issue, and for many of those metrics there are also commonly-cited standards for levels of complexity that are sources of concern. But its still, ultimately, a matter of opinion that the particular measure and standard are really too complex for the purpose the particular code is serving in the particular project, so while you can get some facts, the relevant bit still boils down to a matter of opinion. OTOH, the best proof that code is too complex is to demonstrate simpler code that does the same thing. If it's someone else's code, there are bigger challenges in the workplace than code complexity. The idea that it matters to whom something about the code is proved is a symptom of them. Software is all about tradeoffs, and there are so many ways a single problem could be solved. What works for me is to show them an alternative way that the code could be written. Then you can have a practical discussion about the differences and what the differences are. Maybe their code is complex because they are considering more scenarios. Sometimes, (not always), complex code is difficult to test. When I hear "the test is hard to write", it's a small to me that the code might be too complex. These are the ones I really agree on.
1. If you can show an easy way, show it to him and hope for the best for him to next time he'll pay attention to use an easy to understand code if possible.
2. If your company goes for testing, show his/her code is hard to test. Other than these aims in particular, you'll probably be ignored. I have been on the other side of table where a coworker told me that my code was complex. But at doing that he appreciated the code that it worked as expected and how quickly I made it work, he taught me that in long run though, how a complex code would lead to various bugs. Show him examples, show him how to refactor that and convert the same code into a beautiful code. So, my advice would be to give something back to the developer in case you want him to listen to you. Sure, you can prove it is complex by measuring cyclomatic complexity. But, the harder part is to prove that complexity matters. (I don't think it does myself). Have you considered that maybe it doesn't matter? Is his code well tested, easily maintainable, ships with few bugs, and is produced on time? If so, who cares about complexity? You got two options : 1.Give him a better solution and prove that it can be done better
2.Let him drown and drag you in too. Actually, at a paid job, you can't really redo your coworkers tasks and also get your own done. Not being paid to do that. What you are saying is true, but it's still very relative since it depends on the situation you are in. Code Climate has a scoring algorithm that looks at the quality of your code, including its complexity. Do you mean "too complex for what it's trying to solve?" - you can prove that with a simpler, cleaner solution to compare against. Don't bother, it's just an argument with no useful outcome likely. Do good work. Improve yourself. Don't worry, none of it really matters. Ask him to change it in some meaningful way and document the struggle.
