I committed to the GnuCash codebase pretty regularly in the 1999-2002 era... I think maybe I actually implemented the fractional representation that the article discusses? Not sure, it was a long time ago! I definitely remember receiving some very heated emails about how this was total nonsense and there was no reason to do anything other than a decimal representation. The phrase "a superhighway of abstraction, leading nowhere" has stuck with me for lo these many years :) good times

Thanks for the info! But did you guys thought about fractional commodities those days? Or was it clear that it is going away?

I seem to remember that we were aware that fractional commodities were going away, but exact rational values would still be important to be able to represent historical holdings and transactions.

In hindsight do you think it was an right decision or too "pure"?

I guess I don't really have an opinion about that. Certainly an exact representation of decimal numbers was essential, and was something we needed to implement at the time, but going to a fully rational numeric stack was arguably overkill.

The current value of held assets in another currency isn't really "counting" any more, it's a prediction of the outcome of some future transaction that hasn't happened. So I'm less concerned about exactly computing it than I am in never making a mistake in assets that I am counting, i.e. keeping in one account and only incrementing and decrementing the amount when a transaction occurs.

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well.

They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else.

Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.

“Sign up and pay at least part of it now and we’ll prioritize the feature”.

I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.

Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?

If the competitor already has it why are you talking to me? :)

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

No, parent said they’d go talk to the competitor. They didn’t say they were already with them. Don’t change the scenario.

Because you have other benefits, so we'd really like to use you, but we can't unless you support this dealbreaker feature that your competitor has.

Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.

I understand the intuition, but it's a misunderstanding of how software sales operates. There's no tradeoff between prospects who need new features and prospects who don't, because salespeople love that second category and you'll have no problem hiring as many as you need to handle all of them.

The top down push for timelines is because:

In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.

I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.

Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.

The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.

1. Think about what product/system you want built.

2. Think about how much you're willing to invest to get it (time and money).

3. Cap your time and money spend based on (2).

4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.

If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.

How would you decide between doing project (a) this quarter, or project (b)?

If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI.

To rationally allocate money to something, someone has to do the estimate.

The exact same way you'd treat any other investment decision.

In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.

You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.

You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).

When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.

What you're asking is the equivalent of going to a company whose equity you've bought and asking them: what's the price going to be in 6 months' time?

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.

I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.

I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.

Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...

How much plumbing knowledge do you have?

I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.

But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.

I think this is unfair to sales.

I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise.

When will you recover from your injury so you can play the world cup?

When will this product arrive that I need for my child's birthday?

When will my car be repaired, that I need for a trip?

How soon before our competitors can we deliver this feature?

"It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.

But it's the reality of engineering. If reality is unacceptable, that's not reality's problem.

But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.

So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.

The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.

I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world).

It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better?

And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly).

I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets).

Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.

> maybe it's also our fault and we can do better?

Part of it is absolutely our fault; part of it is the industry.

In the electronics world, when you need <common functionality>, you can find an off-the-shelf part that fits your requirements, fit that part in and it'll work. When you need logic in a hardware device, nobody's rolling their own CPU from discrete parts - they just take the cheapest microcontroller fitting the requirements.

In the software world we don't seem to have this concept of building blocks for common functionality even decades into the industry. Most software projects are some flavor of CRUD app with custom logic operating on the CRUDed objects. You'd think all the complexity would be in the custom logic, but actually it's at best 50-50 and at worst most of the complexity is in the whole CRUD bullshit and not what happens to the object once it's CRUD'ed.

How come in 2026 there's still no way to have an off-the-shelf component I can buy to do "I have a table of objects on the server, and I want to expose this as a UI to the client"? Why do I still see people writing this by hand in React/$JS-framework-of-the-day and messing around with things like OpenAPI and/or writing serializers/deserializers by hand? I swear most of the work I see in the web development space is the minutia between client/server communication.

I think there are several reasons:

* overengineering/resume-driven-development: even if there was to be an off-the-shelf component to do the task, people would probably avoid it and prefer to bullshit around reimplementing a (worse) solution. That's already the case where people are using React/SPAs/etc for views that do no need any interactivity and could just be an HTML form.

* political choices influencing tech selection: more often than not some tech or service provider is selected based on political reasons and not technical, and then the engineering challenge becomes as to how to shoehorn this ill-fitting part into our solution.

* aversion to paid software: hardware engineers are expected and allowed to select parts that cost money. I've never been on a software project where we had an explicit budget for licensing software. Reaching for paid software became the least resort option I'd have to fight for and burn political points, while spending 10x the cost building a (shittier) replica in-house was considered fine.

Due to the last point there's also little incentive for software providers to build and sell such components, so the market is quite small and not competitive, with the (very few) competitors having their own dealbreakers. Firebase will give you the instant database and UI, but then you're forever tied to paying them rent. You can't just license the server component and install it in-house like you can buy an FPGA.

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy?

If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person?

The no estimates movement has been incredibly damaging for Software Engineering.

If work on a house was specified like a typical software project, no builder would even return your call.

"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".

Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.

When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”

The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.

Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.

And often the timeline slips by weeks or months for no discernible reason.

Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.

But the correct response to that is not - "I'm not going to tell you how long that will take" it's "let's work out what you are trying to accomplish".

Though the "I'm replacing your crew every three days" does cut a little too close the bone...

Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted.

I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.

If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)

All software requests are somewhere in between former and latter, most often leaning towards the former scenario.

Building a house, adding an extension, replacing a bathroom, building a deck. Many unknowns - you'd still expect an estimate.

When there are huge unknowns, such as in the case of a remodel where who knows what you might find once the drywall is removed, then yes. I happily worked with a contractor on a basement renovation with no estimate for this exact reason.

If it’s something where they have fewer unknowns and more control and lots of experience building the same thing, then I would expect an estimate: building a deck, re-roofing a house, etc

For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.

Definitely so. Most business people that I've worked with do understand that. And provided problems are communicated early enough can manage expectations.

Where I've seen issues is when there is a big disconnect and they don't hear about problems until it's way too late.

My experience with contractors is limited, but in all nontrivial cases I recall they took longer than estimated and it ended up costing more.

Most businesses like to pretend change orders don't apply to software.

Then you need a new estimate. That is not hard to comprehend.

Anybody who worked with a local contractor knows that their estimate and the reality has no correlation.

When you ask for a firm estimate, you are basically asking to be lied to, and the contractor happily complies by telling you a lie.

These are just bad contractors. I used to work for a remodeling company. We came in under time on the vast majority of projects because the guy who ran the company knew what he was doing and built slack into the schedule.

Anyone from a sales roll care to speak to this?

Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.

Are you in sales or have you ever worked in sales?

I've been a CTO (with a lot of pre-sales engineering responsibilities) and a VPE responsible for engineering - sales relationships; I've participated in hundreds of prospecting and customer calls and many years of sales planning/strategy/deal review meetings. I can tell you from first hand experience that sales (and marketing, to a large extent) are both strictly measured and held accountable to forecasts. Forecasting a buyer's behavior, or a lead gen pipeline, or deal timing is not easier than forecasting the construction of a new feature.

Really interesting topic. (I’m actually somewhere in between sales and dev - doing Req. Engineering, Concepts and planning).

Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes.

And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.

As it turns out, the magic sauce that makes everything taste better is just ketchup.

It's good (maybe even indispensable) for some things. Please don't go "ketchup native" on my ice cream.

How else are you going to liquidity-stalk that company you left with some options or even shares?

I take my first cup of coffee with a little tea-leaf reading based on the activity of the CEO and my former coworkers. If you ever see more than 5 connections reacting/liking the same thing you know that HR or marketing sent out an email about it.

I feel some genuine grief about what GTK has become.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

I am still skeptical about the value of LLM as coding helper in 2025. I have not dedicated myself to an "AI first" workflow so maybe I am just doing it wrong.

The most positive metaphor I have heard about why LLM coding assistance is so great is that it's like having a hard-working junior dev that does whatever you want and doesn't waste time reading HN. You still have to check the work, there will be some bad decisions in there, the code maybe isn't that great, but you can tell it to generate tests so you know it is functional.

OK, let's say I accept that 100% (I personally haven't seen evidence that LLM assistance is really even up to that level, but for the sake of argument). My experience as a senior dev is that adding juniors to a team slows down progress and makes the outcome worse. You only do it because that's how you train and mentor juniors to be able to work independently. You are investing in the team every time you review a junior's code, give them advice, answer their questions about what is going on.

With an LLM coding assistant, all the instruction and review you give it is just wasted effort. It makes you slower overall and you spend a lot of time explaining code and managing/directing something that not only doesn't care but doesn't even have the ability to remember what you said for the next project. And the code you get out, in my experience at least, is pretty crap.

I get that it's a different and, to some, interesting way of programming-by-specification, but as far as I can tell the hype about how much faster and better you can code with an AI sidekick is just that -- hype. Maybe that will be wrong next year, maybe it's wrong now with state-of-the-art tools, but I still can't help thinking that the fundamental problem, that all the effort you spend on "mentoring" an LLM is just flushed down the toilet, means that your long term team health will suffer.'

> And the code you get out, in my experience at least, is pretty crap

I think that belies the fundamental misunderstanding of how AI is changing the goalposts in coding

Software engineering has operated under a fundamental assumption that code quality is important.

But why do we value the "quality" of code?

* It's easier for other developers (including your future self) to understand, and easier to document. * Easier to change when requirements change * More efficient with resources, performs better (cpu/network/disk) * Easier to develop tests if its properly structured

AI coding upends a lot of that, because all of those goals presume a human will, at some point, interact with that code in the future.

But the whole purpose of coding in the first place is to have a running executable that does what we want it to do.

The more we focus on the requirements and guiding AI to write tests to prove those requirements are fulfilled, the less we have to actually care about the 'quality' of the code it produces. Code quality isn't a requirement, its a vestigal artifact of human involvement in communicating with the machine.

An important point, well made.

Often AI critics say things like “quality is bad or “it made coding errors” or “it failed to understand a large code base”.

AI proponents and expert users understand these constraints and know that these are but actually that important.

I don't know how they get their sources, but it would be nice if it was directly from coding documentation (and not random stackoverflow answers) and if those guides were I don't know, more machine readable? (That's not a passive aggressive use of question marks, I'm genuinely just guessing here)

I don't know that the hardware is dead yet. They got a cash infusion last year and there are occasional hardware updates in their Discord. It's just a slow process with 1-2 engineers total working on the many different hardware and software and firmware elements of the overall product.

Yeah - last update on the web page was, what, December? I think they're going to get outrun by the rest of the market. "Walking dead", possibly. If I can get NUC+XReals+some sort of integrated desktop then they'd need something really compelling to make their headset worthwhile at the price they're aiming at.

There's no hurt feelings like the hurt feelings of a junior engineer, who has spent the last year kvetching about how much they hate working on legacy junk, hearing someone else refer to one of THEIR projects as "legacy junk".

Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.

1 year old code is not legacy. Legacy is a useful category. COBOL is legacy. Maybe it is unclear exactly where to draw the line but if that were a valid reason to discard conceptual categories we wouldn't have any.

I like the definition from "Working Effectively with Legacy Code", Michael Feathers says legacy code is code without tests.

Heh, so true in many cases. I had rewritten a utility that scanned a directory and moved files to s3 from Perl to Go and eventually a different team took over the code. A bug popped up and they were not confident to update the "legacy code." I could do not but chuckle to myself: this was like a fee hundred lines of well organized and fully unit and integration testable code with a readme and runbook and grafana/prometheus and structured logs aggregated in Splunk. And that has been running for like 2 years. They just didn't want to even attempt the fix and in fact pushed it off indefinitely.

Legacy code is code without tests. Doesn't matter if it's new or old.

IMO legacy code is code that has lots of if statements and special cases sprinkled in over the years to enable new features quickly and get out immediate hotfixes for bugs without doing full refactors and/or data migrations to address the root causes. Even with 100% test coverage it’s a pain to build new features in because there are so many paths to think through, and instead of single sources of truth each part of the app assumes every other part is working in very specific ways.

An alternative definition, legacy code is any code where there’s no one left on the team who has been working on it for years and intuitively knows the pitfalls. Then everyone’s scared to touch it or make big refactors, which actually leads to those small special cases being added instead.

I ran face-first into this effect at a successful startup where I started as employee number 9.

When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.

When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.

You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.

You can still buy bikes like that. There are plenty of people still making frame sets that will work with standard drive train components, standard sized stems, and plain ol handlebars in a variety of shapes. And they will build a bike for you.

I bought a Rivendell about 10 years ago and it's probably my last bike. Is a steel frame heavier than carbon? Yes, a bit, but I don't have to throw it away after a crash, it rides like a dream, and the weight difference is less than the extra "water bottles" I carry around my midsection. Most of the weight of the bike+rider (which is what you have to haul around) is the rider, not the bike, and the frame is just a fraction of the weight of the bike!

Even though new bikes are getting more and more proprietary, I don't foresee a time when I can't buy a new Shimano cassette or other replaceable parts.

It does seem like a complete bike that is under $1100 or so today will be less repairable than the bike I got in 2008 for $600 (less than $900 in 2024 dollars).

In some ways yes in other ways no. Shimano has been on their forced obsolescence train for 30 years. They don’t make hoods for my old 8spd levers. If I want to not deal with ratty old tape over sticky ancient hoods I need to drop $130 on new claris levers and $25 on a new fd because the pull ratio changed then another $20 on new bar tape.

>They don’t make hoods for my old 8spd levers.

You should check AliExpress for those. You might be able to find some knock-offs. AE is actually really good for things like this. The other place to check is Ebay, in case someone is selling NOS (new old stock).

I’ve tried both. They don’t make 8spd era hoods they do have some 9spd clones. NOS has n’t existed for years and when it comes up people ask $100 for a set of hoods.

I wonder if any of the companies making 9spd clones would be interested in making 8spd clones. It might not be worth it for them, but probably wouldn't hurt to ask, especially if people are actually getting $100 for a set when they dig up some NOS.

If your hoods aren't absolutely disintegrating into goo, a little talc powder goes a long way towards getting rid of the stickiness.

I tried that too. Talc only works for the first time you grip the hoods. If you then take your hands off and regrip you are back to where you started getting black crap everywhere. Tape has been the best solution if a bit ugly.