9 ms·

I've noticed a lot of developers that have this kind of code purity complex where their way of doing things is superior even if the actual code Works - which I

I've noticed a lot of developers that have this kind of code purity complex where their way of doing things is superior even if the actual code Works - which I think is the number one most important thing about code. The code purity complex is a self-limiting decision. Those developers will be sitting at home fuming, I guess, as I cheerfully build a new feature on VB6 code last changed in 1999 that relies on using "On Error resume next", on an obscene contract rate. Working only with Good code is a luxury decision, and writing Code That Sucks isn't necessarily bad, if thats the fastest/cheapest way to write code that works. The end user almost as a rule, doesn't care about your code purity. A developer probably couldn't even explain that purity in a way that would make the end user understand its value. This method name indicates a lack of understanding that finding the right balance of speed, cost and quality is a compromise. Yes, tests that can run in isolation are "better".

Aeolun 4y ago
> The end user almost as a rule, doesn't care about your code purity. It’s not that they care about the code itself. They care about the 100th feature being delivered at the same speed, and with the save average bug rate as the first.
- tomlockwood 4y ago
  A hundred percent, but sometimes we need to deliver the first feature in order for there even to be a company around to deliver the hundredth.
  - hinkley 4y ago
    Nobody is talking about process for the first feature. Not in this conversation, not in the real world. That's all you. There's always a reason why we should do feature n+1 the same way we did feature n. At some point you have to say stop. You also have to realize that the 'will there be a company around' talk is usually a fiction that gets more work out of the developers. It's a rallying cry, not a statement of fact. Companies run on momentum much of the time. The moment you died isn't the moment the money ran out. It's the moment you didn't avert the money running out. See also 'default dead'. There's a lot of ways to kill a company. Loss of velocity is one of them, and that is dictated most often by tech debt and morale. Eventually the people good at cleaning up messes get tired of only cleaning up messes, and they burn out or leave.
    - tomlockwood 4y ago
      Like I said, there's a bunch of people out there with a "code purity complex where their way of doing things is superior even if the actual code Works".
      - hinkley 4y ago
        You’re just repeating a mantra not engaging. Mostly what I deal with are people whose arguments boil down to “works for me” even when there’s evidence that it doesn’t. Thinking about improvement is hard, and a lot of people find a fictional success to be more fun than an objective one. We shouldn’t confuse “rewarding things are difficult” with “difficult things are rewarding” or “people who want difficult things are difficult people”. Most people are gaming the system. While pretending to play an infinite game, they’re mostly worried about getting the next paycheck with as little hassle as possible. Everybody does this to an extent, but many people make enemies of their future selves, which is not healthy. Then they run away from the problems they created, talking a big talk about Progress and bigger and better things when we all know they’re going to make the same mess again and again. Instead of doing the grownup thing and cleaning up their own messes. They get the same 3 years of experience five times in a row and call it 15 YOE.
        tomlockwood 4y ago
        > You’re just repeating a mantra not engaging. That's an interesting perspective because I feel like the things you're saying are not addressing that point: that "code purity" is a self-limiting and often self-congratulatory mantra.
deleted 4y ago
[deleted]
djur 4y ago
If you don't have a lot of ego about code purity you probably won't mind typing a mildly self-deprecatory thing in your test setup, either.
- tomlockwood 4y ago
  And I guess similarly if someone does care intimately about test ordering they also ought to care that method names are descriptive. Maybe they should have had to call a method named "i_suck_and_dont_care_about_method_name_quality" to put "i_suck" in a method name? I guess its hypocrisy all around in that case.
  - rgoulter 4y ago
    The point of a method name like "I_suck_and_..." is to discourage misusage of the API,or at least provoke conscious thought about whether it's a good choice to make. That the name adds friction is an intended feature, not a bug. Writing or seeing "I_suck_" is obviously going to cause you to stop and think about it. I think there's some reasonable contention about whether "I_suck" is professional, though, sure.
    - tomlockwood 4y ago
      If the API can be misused I think the snarky code purity response here might be to say the API is flawed, and the underlying mechanism that requires "misuse" ought to be fixed. Also another problem is if the API can't sufficiently WARN developers when they're doing something dangerous. I think we all know there are already ways of doing this.
      - rgoulter 4y ago
        > ... I think the snarky code purity response here ... I think if we can agree "taking on tech debt can be a good approach" and has dignity, we also have to agree that wishing for code without tech debt is also dignified. :o) Which is perhaps why the "I_suck_and" gets removed from this property. > If the API can be misused I think ... the API is flawed, and the underlying mechanism that requires "misuse" ought to be fixed. Which in this case would mean "minitest should only be able to run tests in random order". -- I think having an (inconvenient) option as a concession is a reasonable trade off.
agentultra 4y ago
I think there are contexts where this approach is sufficient. But the little Dijkstra in me can’t stand for it in most professional situations. I’m not the kind of programmer that delights in not knowing what I’m doing and fixing the result of my neglect later on. I also charge obscene rates. Usually to fix piles of code no one understands anymore. Tests I find are a bare minimum and are not even sufficient in more cases than people realize. It’s a shame though that even this low bar is too much for some. It’s a good balancing act to know when the enemy of a good plan is a perfect one… and what makes a sufficiently good plan.
- tomlockwood 4y ago
  > I think there are contexts where this approach is sufficient. Absolutely!
- smaudet 4y ago
  "Tests I find are a bare minimum and are not even sufficient in more cases than people realize. It’s a shame though that even this low bar is too much for some." That's in part because some really bad hipster devs decided they knew better and nixed integration testing... "Tests" usually means "happy path and/or unit", which nearly always is that ultra low bar. The amount of testing required to truly validate something of reasonable complexity is so staggeringly high, if your tests run in under an hour you probably didn't test it, or you are building something really, really simple. True testing is about covering the combinatorial explosion, and that's assuming your problem space is decidable.
rgoulter 4y ago
> ... have this kind of code purity complex ... I think it's fair to describe "tests are order dependent" as technical debt. Taking on a bit of technical debt for better code velocity is an option. It may be a good option (depending on the situation); but with such tech debt, there are risks like bugs which might not be found until later, or some other impact which could make it much harder to maintain.
- Aeolun 4y ago
  That, but it also costs me a lot of time to set up and tear down our database. If I had to do that for every test everything would slow to a crawl.
  - hamandcheese 4y ago
    I try hard to mock out the database calls. I know some disagree, but I'm pretty productive and the occasional bug that does slip through because of this is worth the time saved, IMO.
  - ntr-- 4y ago
    don't tear down the entire db for each test, make utilities that create the base objects you need to operate on and chain them together
  - xmcqdpt2 4y ago
    If you can reuse the test db then it's still not order dependent. If your test framework doesn't support reusing setups, you create some kind of function like getOrCreateDbConnection() that idempotently set up your test environment. Order dependent tests happen when you have like a createUserTest and a deleteUserTest and the latter doesn't actually create the user it deletes but requires being called strictly once after createUserTest. Some of our code at work is like that and it's a pain because it means the tests have to run sequentially (slow), you can't run any single test in isolation and if something breaks it sometimes causes a failure in the wrong test.
- tomlockwood 4y ago
  Absolutely agree with you here.
RangerScience 4y ago
> even if the actual code Works - which I think is the number one most important thing about code Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. Exactingly defined requirements, operating contexts, rigorous development processes (thinking of you, NASA checklist). Things like databases and aerospace. Otherwise the two (IMHO) most important things about code are adaptability and maintainability, not correctness; one way I look at is that your code can't be more correct than the product design. Give me pure but incorrect code and I can fix it. Give me impure but correct code and I can't adapt it when the needs change. IMHO (and bias disclaimer: Rubyist here) this is why Rails took over web and Python took over academia / ML - Python is about being correct, Ruby is about being adaptable - so Python is better suited to the well-defined-hard-to-do stuff, and Ruby is better suited to the poorly-defined-easy-to-do. > explain that purity in a way that would make the end user understand its value Challenge accepted! :) Good code breaks down the business and product concepts into good elements, and this has many downstream impacts. You, the end-user, can only use the concepts that we've baked into the product, and the product can only be made out of the concepts that we've baked into the code. The less this is true for something - the more that it's a powerful, flexible tool - the more expertise you need to use it (looking at you, Jira) and the closer it gets to just having you write code yourself. So doing a good job of picking the concepts we use to program a thing impacts how well you, as the end-user, can use those concepts to accomplish your goals and meet your needs. (And that's aside from stability, new-feature rates, etc). Edit: Just to be clear! I am very, very glad that people with your mindset exist and are working on things. I rely on the things that you make that Are Correct when I'm making my Nearly Correct things. So thank you :)
- tomlockwood 4y ago
  > Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. I think code that is adaptable and maintainable but, doesn't work, is universally useless regardless of context. Definitionally, useless. > Challenge accepted! :) Unfortunately I am a HN denizen and therefore disconnected from the world of end users, who are sometimes convinced by my arguments that refactoring and good testing is important, but in some cases aren't, particularly when they have me on an obscene day rate for a 60 day contract where I'm delivering 3 projects on 3 entirely different codebases I've never seen before (one of which it takes me a day and a half to even compile). I have a constant desire to write fast, good, tests, that run in complete isolation and are entirely reflective of how things run in prod. I miss the mark, many times, and I have a feeling even the purists do, since I keep having to refactor their code.
not2b 4y ago
I had a colleague who had founded a successful company, it got acquired and in the process of extending his very elegant work to handle many more cases it ... got worse. Adding features under time pressure to satisfy customers made it much less clean. After fighting it for a while, he eventually sounded more resigned about it, saying "that's what code that makes money looks like". Not sure if it has to be that way.
- tomlockwood 4y ago
  > Not sure if it has to be that way. Neither, but I'm yet to work at a company that both had code and had zero tech debt. I think there's something about capitalism that makes people want to deliver value as soon as possible, and value isn't necessarily dependent on good tests, particularly at the start of a project.
  - ulizzle 4y ago
    You will always have tech debt, it's a matter of degree. Of course, you have to feel what the best ratio is for your project, which is highly dependent on circumstances, but you definitely want as little tech debt as possible. But what does capitalism have to do with anything?
    - tomlockwood 4y ago
      Capitalism drives people to deliver "value" as quickly as possible. That's the profit motive, which is the whole point.
      - ulizzle 4y ago
        The profit motive is about wanting to make money from a project, not about how it's actually achieved. If delivering value must be done slowly to make a profit, so be it. Notice how alcohol is generally more expensive with age (vintage).
        4y ago
kubectl_h 4y ago
Minitest has a number of cheeky little judgments like this [1][2], especially in the docs. That said they support all these things they don't prefer, within reason, and I appreciate that. Minitest is also full of all sorts of weird peccadillos like being written in the "Seattle.rb style" and autloading files in all gems that match a certain path [3]. These are not how I'd structure a plugin framework or write code, but it works and the code is easy to understand and hack on. I've spent a lot of time reading the internals of minitest, monkey patching or generally torturing it in ways they probably wouldn't prefer and it's been a trustworthy, if a little bit judge-y, tool for years. [1] https://github.com/minitest/minitest/blob/master/lib/minitest/spec.rb#L245 https://github.com/minitest/minitest/blob/master/lib/minites... [2] https://github.com/minitest/minitest/blob/master/lib/minitest/spec.rb#L214-L216 https://github.com/minitest/minitest/blob/master/lib/minites... [3] https://github.com/minitest/minitest/blob/master/lib/minitest.rb#L112 https://github.com/minitest/minitest/blob/master/lib/minites...
- tomlockwood 4y ago
  Honestly really enjoy conversational comments, I think documentation that is conversational is amazing.
dan-robertson 4y ago
Having tests not be order dependent is good for cases where you only want to run one test in a file. (There’s a thing people say about wanting all tests to run in some small total time. I think it’s ok for smoke tests – that is, tests that connect everything together and show that the magic smoke is not released – but for more serious testing I think one should expect tests to take a while because they are testing a lot) The theme of the article seems to basically be giving people what you want though: it’s a tool to take on the technical debt of order-dependent tests if one deems the trade off worth it. One could imagine a library with no such option where such tests would just fail due to ordering constraints.
- tomlockwood 4y ago
  > Having tests not be order dependent is good for cases where you only want to run one test in a file. I absolutely understand the value and desire tests that run in isolation. That's super important to me. > One could imagine a library with no such option where such tests would just fail due to ordering constraints. One can also imagine a library with purely descriptive method names! And, perhaps that would be an even better library!
  - dan-robertson 4y ago
    I think it’s reasonable to design the interface to guide users towards not making mistakes that will come back to bite them. Maybe this name is too antagonistic but it just seems basically benign to me.
    - tomlockwood 4y ago
      If code quality is a concern then I feel like it's reasonable for me to want a purely descriptive method name and a better warning mechanism.
- EdwardDiego 4y ago
  It's also good for parallelising test running.
- 4y ago
toomanyrichies 4y ago
> Working only with Good code is a luxury decision, > on an obscene contract rate. Alternate take- being a contractor who gets to roll off the project in 3 months and therefore doesn't have to support the code they write is also a luxury. Those of us who are in-house, on the other hand, do have to support the code we write. And writing Code That Sucks is a great way to burden our colleagues and our future selves with technical debt that is expensive to pay down, if it even gets prioritized in the roadmap at all.
- tomlockwood 4y ago
  I currently work in-house, and am, today, refactoring other people's tech debt! I don't think some of the code I wrote on that contract will ever be altered again. Pretty sure the VB6 runtime will be impossible to find soon, if it isn't already.
  - toomanyrichies 4y ago
    I think I measure tech debt by how easy or hard a piece of code is to change, in response to changing requirements. So yes, I’d agree that if code is never going to be changed again, then the concept of tech debt is less-applicable. That said, predicting which code will or won’t be changed in the future is a difficult prognostication. It seems safer to assume it will be changed on a long enough time span. Then if it’s not, you can be pleasantly surprised.
    - JoeAltmaier 4y ago
      I tell people, code architecture is designing in flexibility you will never use. It's a pretty safe bet you won't guess right.
- lamontcg 4y ago
  I've been in-house and wound up being the last programmer maintaining the massive pile of tech debt. We had ordering issues and couldn't run our tests in parallel due to global state problems. And it wasn't a mistake here or there, it was the accumulation of a decade of issues. I took a few stabs at it, but doing a week or two of work here and there never moved it significantly forwards. The minitest author took a run at fixing a few of the problems and recommended scrapping the tests entirely and doing a full rewrite. There was no way that I had the time to do that (literally, like me). The answer of course was that the company was effectively dead and it was long past time to quit.
craigmcnamara 4y ago
This is a terrible attitude towards code you support for a number of years. It seems like you just get to dump on the next person, so I guess it works for you, but if one of my people sent a hatchet job in for code review they can expect to get an earful until they do it right.
- tomlockwood 4y ago
  Knowing that refactoring for developer ergonomics isn't the first priority of every project is important, I think. If I was working for you I'm sure you'd argue with the C-level well enough to give me the time to write tests that run in isolation, which would give you enough time to give me an earful if I didn't!
  - craigmcnamara 4y ago
    I think it's good to prevent my test suite from becoming unintentionally stateful. People come and go from projects and you have to keep on top of security updates, so being strict about how things are done makes the project easier to manage in the long run.
    - tomlockwood 4y ago
      > I think it's good to prevent my test suite from becoming unintentionally stateful. Agreed.
girvo 4y ago
I think I’m a bit biased. When I was the lead engineer for the front-end for our system at work, I wanted correct “better” code. Now that I’m doing embedded firmware work under incredible hardware constraints, “better” doesn’t mean the same thing anymore.
gnulinux 4y ago
Oh my God, this comment shows up on a lot of these threads about software correctness and I can't disagree more. * Today, modern software is failing left and right. It's a serious problem and it's extremely frustrating. In part, this is because software industry has abysmal correctness practices. In part, this is because when software engineers write code correctness is an afterthought. * Software correctness, is not easily measurable, and therefore cannot be approached as a metric, instead should be approached as a mindset. Software correctness is about designing systems such that bad things cannot happen by definition. When approached this way, seeing instances of unsafe ideas is sufficient red flags and should be removed. This is because the fact that unsafe constructions exist is sufficient evidence that unsafe behavior exists. * When unsafe code is written, it can be shown that it "works", but this takes effort and engineering time. When things are designed such that they cannot fail, it doesn't take effort and engineering time to make sure they "work". This is why designing from the beginning with correctness in mind is superior than writing crap code and then debugging later. * You say working with good code is a luxury, but it's actually the opposite sometimes. Sometimes you can write code that works 99.9% of the time and call it a day. This is a luxury. Some of us can't. Sometimes it really is the case that if software fails 0.01% of the time someone will be physically harmed. In cases like this some software engineers scratch their heads because they know how to fix bugs, but they don't know how not to never add bugs in the first place. Why did I write this comment? In case you wonder: * You say some people have code purity complex, which you use pejoratively. But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. It occurred to me your comment lacks self-awareness in this regard. * You say "developers will be sitting home fuming", as if this out of some abstract religious principle, when there are concrete, sometimes mathematical reasons why certain code purity concepts exist. * You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost.
- tomlockwood 4y ago
  > But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. You better believe that I complain loud and hard about crap code. I complain about how crap other people's code is, and I have the self-awareness to complain about my code that is crap. What I have a problem with is the attitude some people have that developers "suck" because they write crap code. For example, some people write method names that aren't descriptive. It happens. I personally don't think they should be forced to write "I suck" 30 times on their school blackboard because of this. What would that actually achieve? > You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost. No, actually, I do realize this. But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost. From the VB6 example I used before - the runtime will actually be out of all versions of Windows from 2024. But that's a problem for Another Project. You may think that writing "incorrect" code is a self-limiting decision but I can assure you that I am doing fine and my clients/managers/colleagues have generally enjoyed working with me.
8n4vidtmkvmk 4y ago
i did something I'm not sure I'm happy with yet in order to ship a feature in 2 days instead of 6 months. still waiting to see if it blows up. it give a bunch of not so trustworthy users access to a system that's not been thoroughly vetted for security. guess I'll find out if there's any gaps soon.
culi 4y ago
Either you mostly worked by yourself or on a small team or you don't realize how much your coworkers hate you. In my experience, code quality isn't usually about some purity complex. It's a recognition of the fact this code may have been written once but will have to be read many more times
- revscat 4y ago
  I work with someone like this. And yes, we hate him. Unfortunately he’s the CTO. Of a YC-backed company, even!
- tomlockwood 4y ago
  Actually the most common reason I get a job is referrals from ex-coworkers. ed: Also probably worth noting the reason for this may partially be because I don't say their code "sucks".
swat535 4y ago
While it's true that the end user ultimately cares about whether the code works or not, the argument that code purity is a self-limiting decision ignores the long-term costs of not prioritizing code quality. Code that "works" in the short term may have unforeseen consequences down the line, such as increased maintenance costs, difficulty scaling, or even security vulnerabilities. It's also important to consider the impact on other developers who may need to work on the same code in the future - writing messy code can create confusion and make it harder to collaborate effectively. More to it, the idea that working only with "good code" is a luxury decision assumes that writing clean, well-structured code is inherently more time-consuming or costly than writing messy code. A well seasoned engineer should be able to balance both because they know that better architecture will ultimately save time and money in the long run by reducing the need for debugging and maintenance, and making it easier to add new features.
- tomlockwood 4y ago
  > More to it, the idea that working only with "good code" is a luxury decision assumes that writing clean, well-structured code is inherently more time-consuming or costly than writing messy code. If I let juniors push code to master only if it adhered perfectly to my vision of "good code" I can assure you that I'd be consuming a lot of time. But, just because they don't use list comprehensions or lambdas or accidentally throw around state or whatever doesn't mean that they "suck".
deleted 4y ago
[deleted]
015a 4y ago
If you need a metaphor to understand this perspective: there's a difference between building a bridge that gets some cars over it, and building a bridge that will continue to get cars over it, in thirty years, while accounting for the expected investment of maintenance over those thirty years, and supporting an expanded pedestrian and bike lane added ten years down the line, to the best of the ability of the engineer during the initial planning, while keeping build costs under control. Yeah; working only with Good code is a luxury. But simultaneously, admitting to recognize "It Works" as the most important metric to evaluate good engineering practices by is quite literally what led to the East Palestine disaster last week. Being able to abscond from the responsibility of the repercussions of your "It Works" solution is also a luxury; or, charging those "obscene contracting rates" you talk about. Software Engineering is nascent. We don't always know, and even less often have a good shared language to talk about, what is "The Right Decision" in every context. That isn't an excuse to not try.
- tomlockwood 4y ago
  I simply won't take the job if someone demands I do a rush job of programming train braking systems. It seems like you're reading into what I'm saying a commitment to "not trying" and "[a] metric for evaluating good engineering practices". I'm absolutely not, I'm arguing against the kind of sneering belief in self-superiority that leads some software developers to feel like someone who uses a particular method or way of making working software, "sucks".
  - tacitusarc 4y ago
    There’s a balance here, and it’s important to recognize that often the “but the code works” mantra is used by the lazy or incompetent to justify poorly written code. I think everyone has been burned by something different, and sometimes we read internet comments that are easy to misinterpret as supporting The Thing We Hate That Burned Us.
- koonsolo 4y ago
  You have the wrong metaphor, since bridge projects are all more or less the same, but software projects aren't. I like the shed and skyskraper metaphor better. It makes a clear distinction that some projects are sheds (can be a single script) all the way up to skyscrapers. Some projects don't even need to be extended afterwards, like most computer games.
koonsolo 4y ago
That's the difference between builing a shed and building a skyscraper. And most developers don't understand that sometimes you want to build a shed. In that case, applying the skyscraper building conventions is overkill. Of course building a skyscraper like a shed will never get you past the 4rth floor without the whole thing collapsing on you. Also, at the end of a finite project, you can take some shortcuts to get things finished.
- tomlockwood 4y ago
  > In that case, applying the skyscraper building conventions is overkill. Of course, which is why applying grandiose judgements to the people who just choose to build sheds, is misguided in the extreme.
  - koonsolo 4y ago
    Yes indeed, I fully agree. I once insulted an employer with this expression :). I told them that in the past we were building sheds, and that it all went very well. But now there was a skyskraper project, and that they cannot expect us to build that in the same way. I wanted to make clear that this bigger project needed more structure to support it. All they heard was "what??? You think we build sheds???" :D. Nothing wrong with building sheds of course. In fact those are the most fun projects.
alkonaut 4y ago
> even if the actual code Works - which I think is the number one most important thing about code The ability for the team reason about the code, why it works (or not) is at least as important as whether it "works". Writing code that "works" for some short period of time is often trivial. There are situations when that's necessary or acceptable (solo project, proof of concept, short runway startup, whatever). But it's a debt decision that must not be taken lightly. > Working only with Good code is a luxury decision It's the cheapest decision long term. And that's even before measuring staff retention and other cost driving factors.
- tomlockwood 4y ago
  > But it's a debt decision that must not be taken lightly. Agreed. > It's the cheapest decision long term. And that's even before measuring staff retention and other cost driving factors. I usually agree. In my example, VB6 is well past EOL, and pretty soon it'll be hard to even run the code.
crabbone 4y ago
So, I worked with this one guy who then was promoted to become the product manager. His code "worked" in the way you describe. I.e. it didn't really work, but it worked enough for him to move on to the next glorious moment in his career. And, yeah, people will recommend him to their employers if those ask. He has a good track record of having "things done". People recommend him because he knows people, not because he's a good programmer. It's not just that one guy, it's kind of a personality profile that for some reason lacks the drive to make good things. Not in so major way how psychopaths lack empathy, but I think about it in the same way as being a personality problem, not any kind of strategic decision. It's normal for humans to want to do their job well. Regardless of financial situation or other "practical" concerns. It's a value into itself. Back to that one guy. So, in his head, he generated great value for the company by designing external interfaces. He believed that his contribution was in making the interface to the product easy because his theory of how other people behaved was based on his own behavior: he didn't like to work hard to understand whatever he was doing, he just wanted to see a result on the most basic good-path test to declare his work complete. I really hated to work with him because I felt like I have to mop up after a drunk teenager party every time he added more glorious contributions to the code base and was happy to see him promoted into management until I realized how much of a bad deal it was. From just being bad code that needed fixing this became bad design that had, well, no real way of fixing. Just to give you an example: the product was meant to have HTTP interface to its internal state. Some operations could take a very long time, so there's no way around it -- it had to be asynchronous. The subject of this comment designed the interface in such a way that polling for the state change wasn't in any way tied to the request that asked for the state change. This means that in rare cases, should there be an error while two clients are accessing the API one could see the success response to the request made by the other and stop polling, while the error would've been lost. Of course, errors are rare, and races involving errors are exceedingly rare, so even to reproduce such a condition in a test wasn't a trivial task. Also, the whole idea that the "simple and user-friendly" interface design must change because some grumpy dude showed that in some rare cases it doesn't work didn't sit well with the author of the interface. The problem is... this product is a distributed block storage system. It has to be extremely reliable in order to be successful. I couldn't imagine anyone would deliberately ignore an obvious design error in a system like that, but when that happened, I lost confidence and interest in the product and left the project in a matter of months. Of course, no one is indispensable, but the project lost a senior programmer in a niche field who dedicated many years to working on the project. Realistically, no matter how good my replacement was, they'd have to spend upwards of a year to just bring them up to speed on whatever I was doing. To the best of my knowledge, they never did. Eventually, they stripped the project down to parts, threw away some, repurposed some others, let most of the core team go and rebranded it as something else. I blame that one guy for the failure of otherwise interesting and potentially useful thing.
adrr 4y ago
End users(aka your product managers) care about developer efficiency. Let use the article on this post. When you have a large code base with lots of unit tests. You want the ability to parallelize tests so it doesn't have an hour to run all the units tests. That wait time will kill developer efficiency. Waiting to see if your code will break build and also having integration tests take over hour will guarantee that you will have broken code in source code repository because devs won't wait an hour to run units tests locally and just will merge stuff especially EOD Friday.
- tomlockwood 4y ago
  > End users(aka your product managers) care about developer efficiency. Not in my experience, particularly when you have a day to do something and are saying it'll take a day and a half, and not delivering additional functionality as a result of that extra half day.
raxxorraxor 4y ago
> fastest/cheapest way to write code that works Pretty much. I do really like good code and I hate touching anything that I have written and know it to be bad. But some things need to be done quick. If I open another project that needs to be green-lit for every single thing... Also I do a lot of hardware control and some tests really need a defined order. Sure, these stricly aren't "unit" tests, but there are just a very large amount of conditions that must be met. Components that need time to move, components that have a longer cooldown/heating period that you cannot toggle on/off at all times or in generally should be toggled as rarely as possible. To test that your code is correct, an order to do things might just be sensible and practical. How long a test lasts is also a quality that should not be neglected. Embryonic position after each "unit" is tested would drag everything out. But I have no problem with the requirement to call a most vulgar function to be allowed to do so. Doesn't hurt to reiterate the ideal. It should be said that from small engineering offices to large market leading industry leaders it is still quite common that there are no tests at all...

Aeolun 4y ago

> The end user almost as a rule, doesn't care about your code purity. It’s not that they care about the code itself. They care about the 100th feature being delivered at the same speed, and with the save average bug rate as the first.

tomlockwood 4y ago
A hundred percent, but sometimes we need to deliver the first feature in order for there even to be a company around to deliver the hundredth.
- hinkley 4y ago
  Nobody is talking about process for the first feature. Not in this conversation, not in the real world. That's all you. There's always a reason why we should do feature n+1 the same way we did feature n. At some point you have to say stop. You also have to realize that the 'will there be a company around' talk is usually a fiction that gets more work out of the developers. It's a rallying cry, not a statement of fact. Companies run on momentum much of the time. The moment you died isn't the moment the money ran out. It's the moment you didn't avert the money running out. See also 'default dead'. There's a lot of ways to kill a company. Loss of velocity is one of them, and that is dictated most often by tech debt and morale. Eventually the people good at cleaning up messes get tired of only cleaning up messes, and they burn out or leave.
  - tomlockwood 4y ago
    Like I said, there's a bunch of people out there with a "code purity complex where their way of doing things is superior even if the actual code Works".
    - hinkley 4y ago
      You’re just repeating a mantra not engaging. Mostly what I deal with are people whose arguments boil down to “works for me” even when there’s evidence that it doesn’t. Thinking about improvement is hard, and a lot of people find a fictional success to be more fun than an objective one. We shouldn’t confuse “rewarding things are difficult” with “difficult things are rewarding” or “people who want difficult things are difficult people”. Most people are gaming the system. While pretending to play an infinite game, they’re mostly worried about getting the next paycheck with as little hassle as possible. Everybody does this to an extent, but many people make enemies of their future selves, which is not healthy. Then they run away from the problems they created, talking a big talk about Progress and bigger and better things when we all know they’re going to make the same mess again and again. Instead of doing the grownup thing and cleaning up their own messes. They get the same 3 years of experience five times in a row and call it 15 YOE.
      - tomlockwood 4y ago
        > You’re just repeating a mantra not engaging. That's an interesting perspective because I feel like the things you're saying are not addressing that point: that "code purity" is a self-limiting and often self-congratulatory mantra.

deleted 4y ago

[deleted]

djur 4y ago

If you don't have a lot of ego about code purity you probably won't mind typing a mildly self-deprecatory thing in your test setup, either.

tomlockwood 4y ago
And I guess similarly if someone does care intimately about test ordering they also ought to care that method names are descriptive. Maybe they should have had to call a method named "i_suck_and_dont_care_about_method_name_quality" to put "i_suck" in a method name? I guess its hypocrisy all around in that case.
- rgoulter 4y ago
  The point of a method name like "I_suck_and_..." is to discourage misusage of the API,or at least provoke conscious thought about whether it's a good choice to make. That the name adds friction is an intended feature, not a bug. Writing or seeing "I_suck_" is obviously going to cause you to stop and think about it. I think there's some reasonable contention about whether "I_suck" is professional, though, sure.
  - tomlockwood 4y ago
    If the API can be misused I think the snarky code purity response here might be to say the API is flawed, and the underlying mechanism that requires "misuse" ought to be fixed. Also another problem is if the API can't sufficiently WARN developers when they're doing something dangerous. I think we all know there are already ways of doing this.
    - rgoulter 4y ago
      > ... I think the snarky code purity response here ... I think if we can agree "taking on tech debt can be a good approach" and has dignity, we also have to agree that wishing for code without tech debt is also dignified. :o) Which is perhaps why the "I_suck_and" gets removed from this property. > If the API can be misused I think ... the API is flawed, and the underlying mechanism that requires "misuse" ought to be fixed. Which in this case would mean "minitest should only be able to run tests in random order". -- I think having an (inconvenient) option as a concession is a reasonable trade off.

agentultra 4y ago

I think there are contexts where this approach is sufficient. But the little Dijkstra in me can’t stand for it in most professional situations. I’m not the kind of programmer that delights in not knowing what I’m doing and fixing the result of my neglect later on. I also charge obscene rates. Usually to fix piles of code no one understands anymore. Tests I find are a bare minimum and are not even sufficient in more cases than people realize. It’s a shame though that even this low bar is too much for some. It’s a good balancing act to know when the enemy of a good plan is a perfect one… and what makes a sufficiently good plan.

tomlockwood 4y ago
> I think there are contexts where this approach is sufficient. Absolutely!
smaudet 4y ago
"Tests I find are a bare minimum and are not even sufficient in more cases than people realize. It’s a shame though that even this low bar is too much for some." That's in part because some really bad hipster devs decided they knew better and nixed integration testing... "Tests" usually means "happy path and/or unit", which nearly always is that ultra low bar. The amount of testing required to truly validate something of reasonable complexity is so staggeringly high, if your tests run in under an hour you probably didn't test it, or you are building something really, really simple. True testing is about covering the combinatorial explosion, and that's assuming your problem space is decidable.

rgoulter 4y ago

> ... have this kind of code purity complex ... I think it's fair to describe "tests are order dependent" as technical debt. Taking on a bit of technical debt for better code velocity is an option. It may be a good option (depending on the situation); but with such tech debt, there are risks like bugs which might not be found until later, or some other impact which could make it much harder to maintain.

Aeolun 4y ago
That, but it also costs me a lot of time to set up and tear down our database. If I had to do that for every test everything would slow to a crawl.
- hamandcheese 4y ago
  I try hard to mock out the database calls. I know some disagree, but I'm pretty productive and the occasional bug that does slip through because of this is worth the time saved, IMO.
- ntr-- 4y ago
  don't tear down the entire db for each test, make utilities that create the base objects you need to operate on and chain them together
- xmcqdpt2 4y ago
  If you can reuse the test db then it's still not order dependent. If your test framework doesn't support reusing setups, you create some kind of function like getOrCreateDbConnection() that idempotently set up your test environment. Order dependent tests happen when you have like a createUserTest and a deleteUserTest and the latter doesn't actually create the user it deletes but requires being called strictly once after createUserTest. Some of our code at work is like that and it's a pain because it means the tests have to run sequentially (slow), you can't run any single test in isolation and if something breaks it sometimes causes a failure in the wrong test.
tomlockwood 4y ago
Absolutely agree with you here.

RangerScience 4y ago

> even if the actual code Works - which I think is the number one most important thing about code Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. Exactingly defined requirements, operating contexts, rigorous development processes (thinking of you, NASA checklist). Things like databases and aerospace. Otherwise the two (IMHO) most important things about code are adaptability and maintainability, not correctness; one way I look at is that your code can't be more correct than the product design. Give me pure but incorrect code and I can fix it. Give me impure but correct code and I can't adapt it when the needs change. IMHO (and bias disclaimer: Rubyist here) this is why Rails took over web and Python took over academia / ML - Python is about being correct, Ruby is about being adaptable - so Python is better suited to the well-defined-hard-to-do stuff, and Ruby is better suited to the poorly-defined-easy-to-do. > explain that purity in a way that would make the end user understand its value Challenge accepted! :) Good code breaks down the business and product concepts into good elements, and this has many downstream impacts. You, the end-user, can only use the concepts that we've baked into the product, and the product can only be made out of the concepts that we've baked into the code. The less this is true for something - the more that it's a powerful, flexible tool - the more expertise you need to use it (looking at you, Jira) and the closer it gets to just having you write code yourself. So doing a good job of picking the concepts we use to program a thing impacts how well you, as the end-user, can use those concepts to accomplish your goals and meet your needs. (And that's aside from stability, new-feature rates, etc). Edit: Just to be clear! I am very, very glad that people with your mindset exist and are working on things. I rely on the things that you make that Are Correct when I'm making my Nearly Correct things. So thank you :)

tomlockwood 4y ago
> Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. I think code that is adaptable and maintainable but, doesn't work, is universally useless regardless of context. Definitionally, useless. > Challenge accepted! :) Unfortunately I am a HN denizen and therefore disconnected from the world of end users, who are sometimes convinced by my arguments that refactoring and good testing is important, but in some cases aren't, particularly when they have me on an obscene day rate for a 60 day contract where I'm delivering 3 projects on 3 entirely different codebases I've never seen before (one of which it takes me a day and a half to even compile). I have a constant desire to write fast, good, tests, that run in complete isolation and are entirely reflective of how things run in prod. I miss the mark, many times, and I have a feeling even the purists do, since I keep having to refactor their code.

not2b 4y ago

I had a colleague who had founded a successful company, it got acquired and in the process of extending his very elegant work to handle many more cases it ... got worse. Adding features under time pressure to satisfy customers made it much less clean. After fighting it for a while, he eventually sounded more resigned about it, saying "that's what code that makes money looks like". Not sure if it has to be that way.

tomlockwood 4y ago
> Not sure if it has to be that way. Neither, but I'm yet to work at a company that both had code and had zero tech debt. I think there's something about capitalism that makes people want to deliver value as soon as possible, and value isn't necessarily dependent on good tests, particularly at the start of a project.
- ulizzle 4y ago
  You will always have tech debt, it's a matter of degree. Of course, you have to feel what the best ratio is for your project, which is highly dependent on circumstances, but you definitely want as little tech debt as possible. But what does capitalism have to do with anything?
  - tomlockwood 4y ago
    Capitalism drives people to deliver "value" as quickly as possible. That's the profit motive, which is the whole point.
    - ulizzle 4y ago
      The profit motive is about wanting to make money from a project, not about how it's actually achieved. If delivering value must be done slowly to make a profit, so be it. Notice how alcohol is generally more expensive with age (vintage).
      - 4y ago

kubectl_h 4y ago

Minitest has a number of cheeky little judgments like this [1][2], especially in the docs. That said they support all these things they don't prefer, within reason, and I appreciate that. Minitest is also full of all sorts of weird peccadillos like being written in the "Seattle.rb style" and autloading files in all gems that match a certain path [3]. These are not how I'd structure a plugin framework or write code, but it works and the code is easy to understand and hack on. I've spent a lot of time reading the internals of minitest, monkey patching or generally torturing it in ways they probably wouldn't prefer and it's been a trustworthy, if a little bit judge-y, tool for years. [1] https://github.com/minitest/minitest/blob/master/lib/minitest/spec.rb#L245 https://github.com/minitest/minitest/blob/master/lib/minites... [2] https://github.com/minitest/minitest/blob/master/lib/minitest/spec.rb#L214-L216 https://github.com/minitest/minitest/blob/master/lib/minites... [3] https://github.com/minitest/minitest/blob/master/lib/minitest.rb#L112 https://github.com/minitest/minitest/blob/master/lib/minites...

tomlockwood 4y ago
Honestly really enjoy conversational comments, I think documentation that is conversational is amazing.

dan-robertson 4y ago

Having tests not be order dependent is good for cases where you only want to run one test in a file. (There’s a thing people say about wanting all tests to run in some small total time. I think it’s ok for smoke tests – that is, tests that connect everything together and show that the magic smoke is not released – but for more serious testing I think one should expect tests to take a while because they are testing a lot) The theme of the article seems to basically be giving people what you want though: it’s a tool to take on the technical debt of order-dependent tests if one deems the trade off worth it. One could imagine a library with no such option where such tests would just fail due to ordering constraints.

tomlockwood 4y ago
> Having tests not be order dependent is good for cases where you only want to run one test in a file. I absolutely understand the value and desire tests that run in isolation. That's super important to me. > One could imagine a library with no such option where such tests would just fail due to ordering constraints. One can also imagine a library with purely descriptive method names! And, perhaps that would be an even better library!
- dan-robertson 4y ago
  I think it’s reasonable to design the interface to guide users towards not making mistakes that will come back to bite them. Maybe this name is too antagonistic but it just seems basically benign to me.
  - tomlockwood 4y ago
    If code quality is a concern then I feel like it's reasonable for me to want a purely descriptive method name and a better warning mechanism.
EdwardDiego 4y ago
It's also good for parallelising test running.
4y ago

toomanyrichies 4y ago

> Working only with Good code is a luxury decision, > on an obscene contract rate. Alternate take- being a contractor who gets to roll off the project in 3 months and therefore doesn't have to support the code they write is also a luxury. Those of us who are in-house, on the other hand, do have to support the code we write. And writing Code That Sucks is a great way to burden our colleagues and our future selves with technical debt that is expensive to pay down, if it even gets prioritized in the roadmap at all.

tomlockwood 4y ago
I currently work in-house, and am, today, refactoring other people's tech debt! I don't think some of the code I wrote on that contract will ever be altered again. Pretty sure the VB6 runtime will be impossible to find soon, if it isn't already.
- toomanyrichies 4y ago
  I think I measure tech debt by how easy or hard a piece of code is to change, in response to changing requirements. So yes, I’d agree that if code is never going to be changed again, then the concept of tech debt is less-applicable. That said, predicting which code will or won’t be changed in the future is a difficult prognostication. It seems safer to assume it will be changed on a long enough time span. Then if it’s not, you can be pleasantly surprised.
  - JoeAltmaier 4y ago
    I tell people, code architecture is designing in flexibility you will never use. It's a pretty safe bet you won't guess right.
lamontcg 4y ago
I've been in-house and wound up being the last programmer maintaining the massive pile of tech debt. We had ordering issues and couldn't run our tests in parallel due to global state problems. And it wasn't a mistake here or there, it was the accumulation of a decade of issues. I took a few stabs at it, but doing a week or two of work here and there never moved it significantly forwards. The minitest author took a run at fixing a few of the problems and recommended scrapping the tests entirely and doing a full rewrite. There was no way that I had the time to do that (literally, like me). The answer of course was that the company was effectively dead and it was long past time to quit.

craigmcnamara 4y ago

This is a terrible attitude towards code you support for a number of years. It seems like you just get to dump on the next person, so I guess it works for you, but if one of my people sent a hatchet job in for code review they can expect to get an earful until they do it right.

tomlockwood 4y ago
Knowing that refactoring for developer ergonomics isn't the first priority of every project is important, I think. If I was working for you I'm sure you'd argue with the C-level well enough to give me the time to write tests that run in isolation, which would give you enough time to give me an earful if I didn't!
- craigmcnamara 4y ago
  I think it's good to prevent my test suite from becoming unintentionally stateful. People come and go from projects and you have to keep on top of security updates, so being strict about how things are done makes the project easier to manage in the long run.
  - tomlockwood 4y ago
    > I think it's good to prevent my test suite from becoming unintentionally stateful. Agreed.

girvo 4y ago

I think I’m a bit biased. When I was the lead engineer for the front-end for our system at work, I wanted correct “better” code. Now that I’m doing embedded firmware work under incredible hardware constraints, “better” doesn’t mean the same thing anymore.

gnulinux 4y ago

Oh my God, this comment shows up on a lot of these threads about software correctness and I can't disagree more. * Today, modern software is failing left and right. It's a serious problem and it's extremely frustrating. In part, this is because software industry has abysmal correctness practices. In part, this is because when software engineers write code correctness is an afterthought. * Software correctness, is not easily measurable, and therefore cannot be approached as a metric, instead should be approached as a mindset. Software correctness is about designing systems such that bad things cannot happen by definition. When approached this way, seeing instances of unsafe ideas is sufficient red flags and should be removed. This is because the fact that unsafe constructions exist is sufficient evidence that unsafe behavior exists. * When unsafe code is written, it can be shown that it "works", but this takes effort and engineering time. When things are designed such that they cannot fail, it doesn't take effort and engineering time to make sure they "work". This is why designing from the beginning with correctness in mind is superior than writing crap code and then debugging later. * You say working with good code is a luxury, but it's actually the opposite sometimes. Sometimes you can write code that works 99.9% of the time and call it a day. This is a luxury. Some of us can't. Sometimes it really is the case that if software fails 0.01% of the time someone will be physically harmed. In cases like this some software engineers scratch their heads because they know how to fix bugs, but they don't know how not to never add bugs in the first place. Why did I write this comment? In case you wonder: * You say some people have code purity complex, which you use pejoratively. But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. It occurred to me your comment lacks self-awareness in this regard. * You say "developers will be sitting home fuming", as if this out of some abstract religious principle, when there are concrete, sometimes mathematical reasons why certain code purity concepts exist. * You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost.

tomlockwood 4y ago
> But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. You better believe that I complain loud and hard about crap code. I complain about how crap other people's code is, and I have the self-awareness to complain about my code that is crap. What I have a problem with is the attitude some people have that developers "suck" because they write crap code. For example, some people write method names that aren't descriptive. It happens. I personally don't think they should be forced to write "I suck" 30 times on their school blackboard because of this. What would that actually achieve? > You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost. No, actually, I do realize this. But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost. From the VB6 example I used before - the runtime will actually be out of all versions of Windows from 2024. But that's a problem for Another Project. You may think that writing "incorrect" code is a self-limiting decision but I can assure you that I am doing fine and my clients/managers/colleagues have generally enjoyed working with me.

8n4vidtmkvmk 4y ago

i did something I'm not sure I'm happy with yet in order to ship a feature in 2 days instead of 6 months. still waiting to see if it blows up. it give a bunch of not so trustworthy users access to a system that's not been thoroughly vetted for security. guess I'll find out if there's any gaps soon.

culi 4y ago

Either you mostly worked by yourself or on a small team or you don't realize how much your coworkers hate you. In my experience, code quality isn't usually about some purity complex. It's a recognition of the fact this code may have been written once but will have to be read many more times

revscat 4y ago
I work with someone like this. And yes, we hate him. Unfortunately he’s the CTO. Of a YC-backed company, even!
tomlockwood 4y ago
Actually the most common reason I get a job is referrals from ex-coworkers. ed: Also probably worth noting the reason for this may partially be because I don't say their code "sucks".

swat535 4y ago

While it's true that the end user ultimately cares about whether the code works or not, the argument that code purity is a self-limiting decision ignores the long-term costs of not prioritizing code quality. Code that "works" in the short term may have unforeseen consequences down the line, such as increased maintenance costs, difficulty scaling, or even security vulnerabilities. It's also important to consider the impact on other developers who may need to work on the same code in the future - writing messy code can create confusion and make it harder to collaborate effectively. More to it, the idea that working only with "good code" is a luxury decision assumes that writing clean, well-structured code is inherently more time-consuming or costly than writing messy code. A well seasoned engineer should be able to balance both because they know that better architecture will ultimately save time and money in the long run by reducing the need for debugging and maintenance, and making it easier to add new features.

tomlockwood 4y ago
> More to it, the idea that working only with "good code" is a luxury decision assumes that writing clean, well-structured code is inherently more time-consuming or costly than writing messy code. If I let juniors push code to master only if it adhered perfectly to my vision of "good code" I can assure you that I'd be consuming a lot of time. But, just because they don't use list comprehensions or lambdas or accidentally throw around state or whatever doesn't mean that they "suck".

deleted 4y ago

[deleted]

015a 4y ago

If you need a metaphor to understand this perspective: there's a difference between building a bridge that gets some cars over it, and building a bridge that will continue to get cars over it, in thirty years, while accounting for the expected investment of maintenance over those thirty years, and supporting an expanded pedestrian and bike lane added ten years down the line, to the best of the ability of the engineer during the initial planning, while keeping build costs under control. Yeah; working only with Good code is a luxury. But simultaneously, admitting to recognize "It Works" as the most important metric to evaluate good engineering practices by is quite literally what led to the East Palestine disaster last week. Being able to abscond from the responsibility of the repercussions of your "It Works" solution is also a luxury; or, charging those "obscene contracting rates" you talk about. Software Engineering is nascent. We don't always know, and even less often have a good shared language to talk about, what is "The Right Decision" in every context. That isn't an excuse to not try.

tomlockwood 4y ago
I simply won't take the job if someone demands I do a rush job of programming train braking systems. It seems like you're reading into what I'm saying a commitment to "not trying" and "[a] metric for evaluating good engineering practices". I'm absolutely not, I'm arguing against the kind of sneering belief in self-superiority that leads some software developers to feel like someone who uses a particular method or way of making working software, "sucks".
- tacitusarc 4y ago
  There’s a balance here, and it’s important to recognize that often the “but the code works” mantra is used by the lazy or incompetent to justify poorly written code. I think everyone has been burned by something different, and sometimes we read internet comments that are easy to misinterpret as supporting The Thing We Hate That Burned Us.
koonsolo 4y ago
You have the wrong metaphor, since bridge projects are all more or less the same, but software projects aren't. I like the shed and skyskraper metaphor better. It makes a clear distinction that some projects are sheds (can be a single script) all the way up to skyscrapers. Some projects don't even need to be extended afterwards, like most computer games.

koonsolo 4y ago

That's the difference between builing a shed and building a skyscraper. And most developers don't understand that sometimes you want to build a shed. In that case, applying the skyscraper building conventions is overkill. Of course building a skyscraper like a shed will never get you past the 4rth floor without the whole thing collapsing on you. Also, at the end of a finite project, you can take some shortcuts to get things finished.

tomlockwood 4y ago
> In that case, applying the skyscraper building conventions is overkill. Of course, which is why applying grandiose judgements to the people who just choose to build sheds, is misguided in the extreme.
- koonsolo 4y ago
  Yes indeed, I fully agree. I once insulted an employer with this expression :). I told them that in the past we were building sheds, and that it all went very well. But now there was a skyskraper project, and that they cannot expect us to build that in the same way. I wanted to make clear that this bigger project needed more structure to support it. All they heard was "what??? You think we build sheds???" :D. Nothing wrong with building sheds of course. In fact those are the most fun projects.

alkonaut 4y ago

> even if the actual code Works - which I think is the number one most important thing about code The ability for the team reason about the code, why it works (or not) is at least as important as whether it "works". Writing code that "works" for some short period of time is often trivial. There are situations when that's necessary or acceptable (solo project, proof of concept, short runway startup, whatever). But it's a debt decision that must not be taken lightly. > Working only with Good code is a luxury decision It's the cheapest decision long term. And that's even before measuring staff retention and other cost driving factors.

tomlockwood 4y ago
> But it's a debt decision that must not be taken lightly. Agreed. > It's the cheapest decision long term. And that's even before measuring staff retention and other cost driving factors. I usually agree. In my example, VB6 is well past EOL, and pretty soon it'll be hard to even run the code.

crabbone 4y ago

So, I worked with this one guy who then was promoted to become the product manager. His code "worked" in the way you describe. I.e. it didn't really work, but it worked enough for him to move on to the next glorious moment in his career. And, yeah, people will recommend him to their employers if those ask. He has a good track record of having "things done". People recommend him because he knows people, not because he's a good programmer. It's not just that one guy, it's kind of a personality profile that for some reason lacks the drive to make good things. Not in so major way how psychopaths lack empathy, but I think about it in the same way as being a personality problem, not any kind of strategic decision. It's normal for humans to want to do their job well. Regardless of financial situation or other "practical" concerns. It's a value into itself. Back to that one guy. So, in his head, he generated great value for the company by designing external interfaces. He believed that his contribution was in making the interface to the product easy because his theory of how other people behaved was based on his own behavior: he didn't like to work hard to understand whatever he was doing, he just wanted to see a result on the most basic good-path test to declare his work complete. I really hated to work with him because I felt like I have to mop up after a drunk teenager party every time he added more glorious contributions to the code base and was happy to see him promoted into management until I realized how much of a bad deal it was. From just being bad code that needed fixing this became bad design that had, well, no real way of fixing. Just to give you an example: the product was meant to have HTTP interface to its internal state. Some operations could take a very long time, so there's no way around it -- it had to be asynchronous. The subject of this comment designed the interface in such a way that polling for the state change wasn't in any way tied to the request that asked for the state change. This means that in rare cases, should there be an error while two clients are accessing the API one could see the success response to the request made by the other and stop polling, while the error would've been lost. Of course, errors are rare, and races involving errors are exceedingly rare, so even to reproduce such a condition in a test wasn't a trivial task. Also, the whole idea that the "simple and user-friendly" interface design must change because some grumpy dude showed that in some rare cases it doesn't work didn't sit well with the author of the interface. The problem is... this product is a distributed block storage system. It has to be extremely reliable in order to be successful. I couldn't imagine anyone would deliberately ignore an obvious design error in a system like that, but when that happened, I lost confidence and interest in the product and left the project in a matter of months. Of course, no one is indispensable, but the project lost a senior programmer in a niche field who dedicated many years to working on the project. Realistically, no matter how good my replacement was, they'd have to spend upwards of a year to just bring them up to speed on whatever I was doing. To the best of my knowledge, they never did. Eventually, they stripped the project down to parts, threw away some, repurposed some others, let most of the core team go and rebranded it as something else. I blame that one guy for the failure of otherwise interesting and potentially useful thing.

adrr 4y ago

End users(aka your product managers) care about developer efficiency. Let use the article on this post. When you have a large code base with lots of unit tests. You want the ability to parallelize tests so it doesn't have an hour to run all the units tests. That wait time will kill developer efficiency. Waiting to see if your code will break build and also having integration tests take over hour will guarantee that you will have broken code in source code repository because devs won't wait an hour to run units tests locally and just will merge stuff especially EOD Friday.

tomlockwood 4y ago
> End users(aka your product managers) care about developer efficiency. Not in my experience, particularly when you have a day to do something and are saying it'll take a day and a half, and not delivering additional functionality as a result of that extra half day.

raxxorraxor 4y ago

> fastest/cheapest way to write code that works Pretty much. I do really like good code and I hate touching anything that I have written and know it to be bad. But some things need to be done quick. If I open another project that needs to be green-lit for every single thing... Also I do a lot of hardware control and some tests really need a defined order. Sure, these stricly aren't "unit" tests, but there are just a very large amount of conditions that must be met. Components that need time to move, components that have a longer cooldown/heating period that you cannot toggle on/off at all times or in generally should be toggled as rarely as possible. To test that your code is correct, an order to do things might just be sensible and practical. How long a test lasts is also a quality that should not be neglected. Embryonic position after each "unit" is tested would drag everything out. But I have no problem with the requirement to call a most vulgar function to be allowed to do so. Doesn't hurt to reiterate the ideal. It should be said that from small engineering offices to large market leading industry leaders it is still quite common that there are no tests at all...