11 ms·
The same presumption happens for people, too. Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent.
by swanson 11y ago
The same presumption happens for people, too. Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. I think a much more productive and healthy attitude is to assume that everyone was doing the best they could, given their resources, knowledge, and deadlines at the time.
That might be a false assumption (look, some people just don't care) but you gain very little by complaining and getting mad at things that already happened.
We love to complain about things our predecessors did wrong, but often, we don't do those things either :)
- networked 11y agoI believe that the error the article describes comes from the family of "inside view" errors (see https://en.wikipedia.org/wiki/Reference_class_forecasting https://en.wikipedia.org/wiki/Reference_class_forecasting). Taking an outside view instead is a very widely applicable principle.
- hn_in_cl2 11y agoThere's also the fact that decisions can be very hard to un-make (even in something as malleable as code). This can lead to a bunch of slightly bad/messy decisions all coming together into something that is unimaginably messy/obtuse.
- huhtenberg 11y ago> Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. Don't over-generalize. There is a messy code and there is a messy code. Changing shared data without synchronization is incompetence, but having a 3-page long for-loop is not. In reality though, once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there.
- zzalpha 11y ago> once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there. Question is, where's the incompetence? Yup, like any profession, there are developers out there who just suck. But the same is true of middle and senior company management. Can you honestly say you've never cut a corner because some incompetent manager mismanaged the schedule or customer expectations and then forced you to compromise quality in order to meet an absurd date? And in any organization with that type of management, those issues are rarely isolated. Any one manager can do a little damage, but when an organization is dysfunctional, well-meaning coders on the ground may be forced to compromise code quality time and time again in order to deal with unrealistic schedules. Think of it like a professional sports team. Sometimes, yeah, the players just suck. But a bad coach or general manager can have an outsized effect on an organization. Now, I would never claim that all bad code is a product of bad management. Again, some folks just suck at their job. But speaking as a guy in middle management, I'd be willing to believe at least half of the bad code lying around in the real world is a product of an incompetent management structure. Getting back to the article, that would represent the kind of hidden incentive that would cause an outsider to assume developer incompetence, even though the reality is very much different.
- swanson 11y agoI absolutely agree that there exists terrible code and that there are incompetent individuals or folks that simply don't care. But if one assumes that as the default response, I don't think that is very helpful. Even in your example of shared data/synchronization - what if the original developers were told that the code would never need to be thread-safe? Or what if there was a constraint that required this trade-off to be made? It's not so black and white.
- evilduck 11y agoHell, even incompetent looking code (like managing shared resources poorly) can often be explained by a small script done by an amateur turning into a side business and then a full fledged company. Experience and knowledge of an industry beyond software is often many times more valuable than the knowledge of parallel programming. It doesn't mean the code wasn't valuable or good enough at the time, it just no longer meets the rigor and demands, that's why you're employed to work on it. To call everything shitty thats's below your own standards, level of education and experience is a naive view of how software actually exists in the world. Especially when the standard advice given to "idea people" is to learn to code their idea themselves.
- lmm 11y agoIt is helpful. It gives you the confidence to change things. It allows you to feel productive. And it's true often enough that it's a reasonable default, IME.
- Sone7 11y agoThat seems like a dangerous way to feel confident in your own work and abilities to me. Pinning your self worth to comparisons with others is not so helpful, long term, as you might think.
- zorpner 11y agoOver-generalizer, know thyself.
- s_kilk 11y agoAgreed. One example I see all the time is my more liberal/left-leaning friends assuming that their conservative adversaries (especially on the internet) are motivated solely by stupidity. This trips them up when they are confronted with evidence of intelligence and solid reasoning from the people they had presumed to be capable of neither. The reverse also happens of course, with the conservative person characterising their adversary as the stereotypical "Dumb Hippy".
- lotharbot 11y agoAlso happens with religion.
- nugga 11y agoThere is no similarity between that and religion. Religion by definition is an unjustified belief in supernatural - faith. There is no reason or logical backing for it. It is a malfunction of your reasoning system - perhaps heavy cognitive dissonance.
- sbov 11y agoSounds like love. Or friendship.
- deleted 11y ago[deleted]
- lotharbot 11y agoGP said: "assuming that [others] are motivated solely by stupidity." You said: "by definition is an unjustified belief ... no reason or logical backing ... malfunction of your reasoning system" exactly proving the point. You've made a blanket statement regarding anyone who has come to a different conclusion from you regarding the supernatural. It must be stupidity! It can't possibly be justified, or even clear the bar of not-totally-irrational! There's no room to even try to have a conversation, because "by definition" people on the other side are stupid.
- pc86 11y agoSome of the worst code I've had to work with in my nearly 10-year long career so far was written by one of the smartest programmer's I've met. His problem was that everything because an exercise in designing this all-encompassing abstracted-to-hell-and-back web of interfaces, services, aggregates, domains, etc etc. Indicative of this was a request to take a table of data that already existed (on a website) and add a button to export a CSV of that data. For anyone familiar with .NET (and I assume most other languages) if you've already got the data in the format you want to export this is literally a 10-minute task, including a unit test or two for the functionality. His quote was something on order of 18 hours which included time to write a set of TableDataExportService methods that would support a whole host of file formats in the future.
- tomjen3 11y agoYAGNI. Software should be implemented as simple as possible, and then refactored as necessary when new functionality is required (the only exception is things you are very sure is going to be needed, e.g a password reset functionality on a password dialog). Anyhow that is my development philosophy.
- pc86 11y agoYeah this was some of the most anti-YAGNI stuff I've seen. Which is not meant to detract from the fact that the code was great 99% of the time. It just took 10x longer than it should have and cost 10x as much and half of it was never used.
- hinkley 11y agoI started on a project filled entirely with 'senior people' once, and was really pumped about the prospect of doing Serious Programming with serious people, instead of doing a bunch of mickey mouse crap. Six months later everything was going horribly wrong because there was not a single one of us who was willing to solve a simple problem with simple code. Everybody was engineering the hell out of every single 'solution' and the code was impossible to read. From this I learned a couple of things. One was that I had not learned as much from my Second System Syndrome as I thought I had. The second was that every project benefits from having people who are entertained by solving 'mundane' problems, to whom you can assign all concerns that are not part of the information architecture. But the most important is that the best solution is -never- the one that is dazzlingly brilliant. It's often the one that's subtly clever (everyone agrees "that works", but some can wax poetic about how great it is at satisfying the concern), but sometimes it's the one that's dead simple. Few solutions are easier to replace than the dead simple one.
- angersock 11y agoThe issue is that, even allowing for good intentions, the fact tends to remain that the code is messy, undertested, and underspecified. I've worked on a legacy codebase where the developer both admitted that the code was a hack job, got guilty-defensive about it, and then refused to schedule any time to help make progress. You just want to shake them by the shoulders and be like "Look, it's fine that you did the best you could, but you need to either help clean up the mess or get out of the way." Chesterton's Fence is wise in moderation--otherwise, it ends up as technological hoarding.
- swanson 11y agoSure - at the end of the day even the best intentions can result in a poor quality output. I've just found that my own personal outlook is much better if I stop complaining about how some other person messed up and focused on where the code is currently and how we can solve the problems at hand given our new knowledge/resources/constraints.
- angersock 11y agoOh, on that I agree. I'm just very frustrated with, having taken those steps, being blocked because ~reasons~.
- ombudsperson 11y agoyou make a very valid point!, Thx, :-)