Of course you're right about today's LLMs, but the author imagines a not-too-unlikely incremental improvement on them unlocking an entirely new surface area of solutions.
I really enjoyed the notion of barefoot developers, local first solutions, and the desire to wrest control over our our digital lives from the financialists.
I find these ideas compelling, even though I'm politically anti-communist.
Wow, what a weird feeling. The authors of this article seem like super smart and experienced guys, but the article itself is introduced with incorrect statements in the very first two sentences and slides downhill from there.
"There is a kind of design distortion that happens when a team chooses to build iteratively instead of looking at all of the requirements at once. Ward Cunningham coined the term technical debt to describe those design distortions."
1) There isn't an option to build software by "looking at all of the requirements at once." The requirements of any (sufficiently complex) project will emerge over the course of development, regardless of whether it's built in an iterative style, or with a much larger investment in planning and design up front. We often work iteratively because we acknowledge this particular aspect of reality and it helps everyone when we work closer to reality, rather than fighting it.
2) Technical Debt does not describe design distortions that arise due to "iterative" development, it describes design problems that arise in every project.
Quantizing the choices for dealing with tech debt into 4 buckets doesn't feel right either. Changing the design of a running system happens along a continuum and the need and benefit vary widely over the course of any given software lifecycle and surrounding (business or other) environment.
Maybe I'm just grumpy this morning, and I think reasonable folks could disagree, but the metaphor at the center of the thesis (tech debt ≅ soon-to-be-deallocated-memory) doesn't hold up for me at all.
Tech debt is sometimes left in place, intentionally or not, for many years. Sometimes we chip away at it, sometimes we stop the world and push on it. Sometimes it's bad enough to throw the whole system away and start over. It's like debt for businesses. It can be valuable to take on some debt if it lets you stay alive long enough to pay it back.
Finally, I'm struggling with this article because tech debt is already a metaphor, that includes information about how, and when to take it on and pay it down.
It's not helpful to layer another, unrelated metaphor on top of it.
Ward Cunningham's original idea of tech debt (see [1], a beauty of concision at just 300 words) is that iterative development distorts your code because you start writing code before you know the requirements, but even so, it's better than waterfall. "The traditional waterfall development cycle has endeavored to avoid programming catastrophy by working out a program in detail before programming begins. We ... [instead use] the alternative, incremental growth ..."
Today, the term "tech debt" includes sloppy code, shortcuts, novice code -- really any kind of bad code. The original conception of tech debt is more limited and tied to waterfall vs iterative process choices. [2]
I would argue that there is the option to look at all the requirements at once. The disconnect with your mental model is in the definition of the piece of software being designed. You’re considering all iterations to be the same piece of software, despite ostensibly having different sets of features and functionality (e.g the ones added over time).
Consider the alternative perspective that each new feature actually makes it a new piece of software. You were able to fully design and specify the original piece up front, thus avoiding technical debt on that piece of software.
I don't think that perspective really holds up to practical scrutiny. The most common sources of tech debt in the real world are when new features are tacked onto existing software without integrating with them fully/smoothly.
As a relatable example, think about how the Control Panel in Windows still uses a 2000s-era UI, even as the Settings menu, and most of the rest of the OS, uses a new UI. The likely reason for this is that it was faster to tack on a new UI and leave the Control Panel as-is. It would've taken more time to refactor the Control Panel from the ground up to accomodate a new UI.
The end result is that there are now two separate settings interfaces, and there is probably some ongoing engineering effort required in maintaining both and keeping them coherent with one another. That's a classic example of tech debt - save time now, but it may cost you later.
But, by your definition, the old UI and the new UI are separate pieces of software, therefore there is no debt. How does that track?
There are some bits of software that are simple enough to describe first and then implement, but just about any software that has more than one person working on it is more complex than that (IME), and for those cases, one might as well just implement it anyway.
There are varying degrees to which a team or business may invest in collecting and negotiating requirements before starting development, and there is obviously some amount of this work that is essential and valuable.
That said, as this planning investment grows beyond some reasonable point, and moves deeper into technical details, it will be composed of more waste and this waste will only become apparent as the people executing discover the real technical and product requirements.
The technical debt we're discussing will become an option immediately as the engineering work begins, and it's up to the team to decide how much, if any debt they are interested in taking on at whatever point in time.
I'm not convinced that it's helpful to conceive of the thing we're all working on and becoming more and more intimately familiar with as a new thing over some randomly selected interval.
There is no reality in which we can fully design or specify everything up front. If the specification were comprehensive, it would be the solution.
In practice, *practice*, we use the term iterative pretty loosely. In fact sort of like this IEEE article, it feels dated now, and was never really true in my experience.
It seemed like the word iterative became a euphemism for “dont worry about it”. I have worked across the entire industry for 30 years, and I have never seen a “true iteration”. On any feature or application. Anything at the end of the sprint that doesnt work is just a bug. Thats not iteration.
Iterative development was just a powerpoint slide for the Scrum Industrial Complex which was hard selling itself and it worked!
This article which seems even more antiquated than Id like to describe, seems to confuse iterative with “having all the requirements at once”. Iteration and the quality of requirements, and the bandwidth to analyze them and design a system dont really have much to do with each other.
And thats why iterative came to be a stand in for “dont worry about it”.
I personally feel that the creators of Scrum or some responsible group of modern architects, should audit the results of supposed iterative development, and do an honest assessment of what it actually is in practice. Because its not what we were sold, and its not iterative. It does result in awfully bad software but there have been other shifts in development practice that have accelerated the awfulness of delivered work in the industry, and Ill just leave it at that.
Please resist the temptation to comment, “because your not doing scrum right”. That was the genius of the Scrum Industrial Complex, to suggest that somehow this simple thing is really magical and complex and keep repeating the same things over and over. Its not magical or complex, its just bad.
As far as the article goes, I have been on projects that did spend over a year ingesting requirements and doing design before starting to code. Its true they usually fail. But thats a money/commitment/time to market problem.
Starting to “code” right away creates some better optics and fewer arguments in meetings. The one who pays the piper calls the tune as always.
For hobbyist use you can just pick a random value and it'll usually work. Open-source hardware can get a product ID for free from https://pid.codes. Small-run commercial hardware can usually get a free product ID from the maker of their USB-capable chip. And once you're big enough that you're designing your own chip, $6,000 isn't such a big deal anymore.
So yes, you are technically right, but it really doesn't matter all that much in practice. USB is by far one of the most accessible major hardware standards out there.
Many chip vendors will give you a PID under their VID if you're making a product. For example this blog post uses and ST chip, and they'll provide a PID if you request it [1] - free of charge, but subject to some conditions.
(Of course if your USB device needs Windows drivers, you'll still have to deal with things like code signing...)
The part that makes me feel most uncomfortable about usb VID/PIDs is that they are only 16bits each. While I don't think 4billion unique commercial USB devices is limit we will reach anytime soon, efficiently managing the available address space is a different question. And unlike IPv4 addresses a range of USB VID/PIDs can't be as easily reused without making the VID/PID meaningless.
By that time they'll just add an extra field to the protocol and assign a special "see other field" VID/PID pair.
For a lot of products the VID/PID combo isn't that important on a protocol level, and there's technically no reason why two completely unrelated products couldn't be using the same pair. In practice you're mainly going to use them for software to target a specific device, for example the Linux HID driver uses it to work around hardware/firmware bugs. But HID devices are self-describing, and that's the main mechanism used by the driver to figure out what has been attached and how to behave.
If modern OSes can do the same to distinguish hardware with the extra field, sharing the same value for backwards compatibility with legacy machines really isn't going to be a big deal. It's not like MAC or IPv4 addresses where a clash will essentially kill all communication.
The problem isn't the combined limit, it's the hard limit on Vendor IDs at 65,535.
Since very few companies have 65,535 products, almost all Product IDs in any given Vendor ID namespace are unused.
That is the maximum number of organizations on Earth that can be issued a USB Vendor ID until the spec is modified. They'll likely introduce a special Vendor ID that indicates to clients they should look elsewhere for the real (and longer) one.
While the rules were more lax many years ago, and some vendors are grandfathered in and can therefore share their Product ID allocation, these behaviors are explicitly prohibited by the USB-IF for newly issued Vendor IDs.
Yes, for a single-use hobby product it doesn't matter much and you can just risk the collision.
And yes, some vendors will generously let you have a Product ID under their Vendor ID, but then your product looks as if it was made by them when your customers plug it in.
If you plan to deploy more than a few devices you'll need a Vendor ID and people should know that there is a relatively large tax in front of that need.
Hard disagree on $6,000 not mattering. We build a small number of devices for severely disabled people and sell a few hundred a year. The USB IF was unwilling to budge at all on their prices and this was a large cost that we did not anticipate, and by the way, is technically shameful.
How much does a fucking number cost?
Well, it depends on how scarce you decide to make it, and of course, what the market will bear.
NXP runs a USB VID/PID Program [0] for small production designs (<10,000 units) that use their MCUs. They’ll give you 3 PIDs for free under one of their VIDs. I use this in my side projects (~200 units) and works pretty well!
.. or use someone else's. I believe there's a hobbyist VID under which you can reserve PIDs, or in many cases you can just copy an existing product if your device is generic enough and you're not planning to sell a big production run.
There's pid.codes which uses a vid of a defunct organization, but before that there was also the F055 vid. I still use that vid because no company will accept that vid, since it's commonly used by foss projects.
> I will think twice now before saying “why couldn’t they just use USB for this?”
I dunno, I think either you're doing a small run and you can just bake in a Teensy or whatever, or you're doing a big run and $6k is a drop in the bucket.
Yeah, I was going to ask about this. I think ST Micro will sublicense you a PID under their VID, but with restrictions, and companies attempting to buy a VID and sell PIDs as a service have been sued?
the GP wasn't talking about the type of structure but the legal organization of the property ownership. Canadian provinces have a Condominium Property Act that defines the legislative framework. The implementation can vary by types of units (ranging from apartment-style to single family homes) and the ownership - typically "you own the inside; communal outside" or "you own the inside & dirt; communal outside and shared public spaces". You don't hear talk of "The HOA" but rather "The Condo Board"
Every time I've made an exception, the entire experience is a net-negative.
Half the time, I can't even get authenticated and then once I'm in, everything is awful. The notifications, the constant chatter, the dozens of topics, the useless search, it shocks me that anyone over the age of 14 uses it at all.
Add to all the broken basics, the fact that your data is now locked away in a vault that will absolutely disappear at some point in the not-too-distant future, and it just makes no sense at all.
> it shocks me that anyone over the age of 14 uses it at all
Our group of 40+ old farts uses Discord exclusively, because we can do it all under the same roof.
Want to chat about stuff, we've got a few channels just to keep them contained (one for each RPG campaign we're playing and separate ones for the few PC games we have time for).
Need to chat during an online game? Discord has video and voice chat as well as screen sharing.
Want to keep a log of a RPG campaign? You can do a "forum" post about it after every session, it's all there in a nice format under the same platform.
When we play online games, like Helldivers 2, everyone can use Discord for voice even when I play with PS5 and the others are PC players. Discord works cross-platform.
Exactly the same experience here in the same demographic. In this friend group, we all have kids and wives and pets and jobs and everything else, but we want to still try to do stuff together. Video games, DnD (though we play PF2E and OSR stuff), we do some book club stuff, we talk about sports and our hobbies, we talk about our kids, our personal and professional lives... We can do text, voice, and video. It's been a great experience for us. We do meet in-person every couple of months for a DnD session but that's typically as often as we can manage with 5 busy schedules to juggle.
Topics are there to limit the messages to just what you're interested in, cutting down the chatter.
If you expect it to be anything different than discord, you'll be disappointed, but there are communities where discord/slack/mattermost model works fine.
I do find it very strange. It assumes I've been "invited" when I just clicked on a link to join from a website. I can't tell why I am or aren't logged in when I join. It's full of animations.
Maybe it's the Gen Z take on IRC, but it seems a bit much. The client is very smooth in performance, though, which is nice.
"Add to all the broken basics, the fact that your data is now locked away in a vault that will absolutely disappear at some point in the not-too-distant future, and it just makes no sense at all."
Who cares? Why do you want to record every single thing forever? Do you write down every single thing when you converse with someone in real life?
And you really can't figure out how to use Discord, when a 14-year old apparently can? Maybe it's time to retire.
yeah any complaints about UX should be seen as boomerism and fought against with your full might with no reflection on the critique. When the water wars come and you have to learn to use a slide rule -- remember this day.
>it shocks me that anyone over the age of 14 uses it at all.
Really? I'm in my mid 30s and am in a couple servers with a bunch of 30-50 year olds. I don't know of any better platform to organize and play DnD with voice chat and screen sharing. It's also great for when I play larger online games with a group (e.g. World of Warcraft, Final Fantasy) as we have a guild server to organize absences, socialize while not raiding, etc.
If you have a suggestion for a better way to voice chat, screen share, drop in and out of conversations, etc. I'm all ears.
For what its worth, all of your complaints (except for search, which really does suck) are easily addressed.
This. I've been loving Zig for some years now, but still write a lot of embedded C at work.
I've started to use simple memory arenas in C and it just feels so damn _nice_.
There's basically a shared lifetime for most of my transient allocations, which are nicely bounded in time by a "frame" of execution. Malloc/Free felt like a crazy amount of work, whereas an arena_reset(&ctx) just moves a pointer back to the first entry.
Another person pointed out that arenas are not destructors, and this is a great point to make. If you're dealing with external resources, moving an arena index back to the beginning does not help - at all.
Just a friendly warning to folks who might think these updates work.
They did not work on my system. If you have a working workstation with NVidia hardware on Ubuntu LTS, keep waiting. Chrome no longer works for me on this mess.
Now take that beautiful application you have made and your customers want, and beg the trolls who sit between you and them for permission to distribute it.
Assuming you get said permission some weeks later, now hand over double-digit percentages of your top-line revenue to these despicable rent-seekers, do the same with your tax payments and notice how you're left with less than 30% of the value you have created.
I really enjoyed the notion of barefoot developers, local first solutions, and the desire to wrest control over our our digital lives from the financialists.
I find these ideas compelling, even though I'm politically anti-communist.
The presentation was also quite lovely.
reply