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? |
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? |
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.
Other than these aims in particular, you'll probably be ignored.
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.
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?
1.Give him a better solution and prove that it can be done better 2.Let him drown and drag you in too.
Do good work. Improve yourself. Don't worry, none of it really matters.
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.
...and one thing that can also happen is, when discussing a secondary solution, a third one can come up that is even better.
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".
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.
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.
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 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.
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.
+1 rich hickey talk
Of course that is not the least resource intensive solution. Code reviews may help.
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.
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...
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.
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.
http://www.amazon.com/Event-Based-Programming-Taking-Events-...
Get it free here:
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.
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.
there is: http://www.osnews.com/images/comics/wtfm.jpg
i'm not even joking.
Further, definitions that rely on one or many observable phenomena are more useful than definitions which rely on subjective experiences.
This isn't really "proof", but in my experience, such a demonstration is easy to understand and leads to constructive conversations and good results.
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.
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.
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.
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.
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
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.
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.
