From my little experience I find this article's point to be true. I've been in a few organisations where the flow of people (students) is constant, so experience constantly leaves and mistakes get repeated (we haven't figured out a proper knowledge base). All one can do is try their best to transfer the experience before graduating, but taught lessons don't stick as deeply as firsthand learnings (with the associated toil...)

This is what people mean when they say build the first version to throw away.

The software development company that I worked at for 20 years, made a specialised practice management system that was (at the time) years ahead of the competition - a real Windows experience with a real database, where the competition was all DOS based or using Access. At one point, they sold the rights to develop their software in a particular country to another company (they had no plans to enter that market, and were a bit strapped for cash at the time). So the other company got the source code, and - in the spirit of the time - insisted it was printed out on paper too! The other company never managed to do anything with it in the end - having the source code for the entire product was not enough!

> And I’d go further than that. I’d suggest that, contrary to what intuition might tell you, refactoring might be better achieved by throwing the code away and starting again.

I don't think this applies in most situations. If you have been part of the original core team and are rewriting the app in the same way, this might be true - basically a lost code situation, like the author was in.

However, if you are doing so because you lack understanding of the original code or you are switching the stack, you will inevitably find new obstacles and repeat mistakes that were fixed in the original prototype. Also, in a real world situation, you probably also have to handle fun things like data import/migration, upgrading production instances and serving customers (and possibly fixing bugs) while having your rewrite as a side project. I'm not saying that a rewrite is never the answer, but the authors situation was pretty unique.

It's a nice thought to have for when I'm mentally dooming about vibe coding killing my job and entire field.

This is a very good point that has been proven over and over again in the industry. I recall being at Sun and having the argument over ONC and whether or not it should be "open" (which at the time meant everyone could get a copy of the code[1]) or "closed". Ed Zander was a big fan of keeping everything secret, after all anyone could reproduce it if they had the code right? And I used the same argument as the author, which is that if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code so keeping the code secret merely slowed them down fractionally but letting our licensees read the code allowed them to better understand what worked and why and could release products that used it faster, which would contribute to its success in the marketplace.

I lost that battle and ONC+ was locked behind the wall until Open Solaris 20 years later. So many people in tech cannot (or perhaps will not) distinguish between "value" and "cost". Its like people who confuse "wealth" and "money". Closely related topics that are fundamentally talking about different things.

This is why you invest in people and expertise, not tools. Anyone can learn a new toolset, but only the people with expertise can create things of value.

[1] So still licensed, but you couldn't use the trademark if you didn't license it and of course there was no 'warranty' because of course the trademark required an interoperability test.

Mostly I just keep seeing all the references to "ajax" in the title image and wondering how old that stock photo is.

“All the value is stored up in the team, the logic and the design, and very little of it is in the code itself.”

This is a key reason it’s so important to knowledge-share within teams. For all kinds of reasons, people move on, and any knowledge they hold without redundancy becomes unavailable.

Also a good reason why commenting can help: then maybe a bit more of the value IS in the code.

Who's time is money^n where n varies by effectiveness. It's not simply a linear relationship. And building a team can make the n's increase together.

The data model in the code is what's important, but more important than that is the discovery and uncovered details that's happened while writing the code. That whole refactoring thing is just a sideshow to the underlying data model changing to better match the real world conditions the software has to run under.

> No. I achieved this because the code contained very little of the real value. That was all stored in my head. The design was in my head, and with hindsight I could see all its flaws. I was therefore able to create a much more efficient and effective design based on that learning.

Exactly. Code is cheap to write. Even a lot of it. What's hard is understanding a problem thoroughly enough to model a correct solution. Once you have that, you've done 90% of the work.

This is the classic, very domain specific wisdom that does not extrapolate to all software. Some codebases are narrow in focus and rely on solving a problem in a smart way. Other applications just need to hold thousands of data points that come from variety of sources. Here the code holds tens of thousands of priceless details that you will inevitably forget like "this integration sends local time but doesn't adjust for daylight savings", and the value of holding these details will persist especially after all the tribal knowledge dissipates.

It's actually the inverse. Code is a liability, software is value. That's why we spent all our time splitting hairs to get more elegant ways to try and produce more software with less code.

The code is valuable insofar as it maps to the real world.

I very much agree with this. Find a job where you can meaningfully contribute to a product that is important to your company (generates a meaningful amount of revenue), and after a little while the natural thing that happens is you become irreplaceable because of that retained value in your head.

It doesn’t have to happen, and with some effort can be somewhat avoided, but it’s the default outcome. Depending on your goals and career aspirations, this can be a wonderful thing, or it can be a bit of a curse.

> The design was in my head, and with hindsight I could see all its flaws. I was therefore able to [re]create a much more efficient and effective design based on that learning. All the mistakes had been made, so I was able to get this version of the code right the first time.

Notice the critically important difference of recreating an existing design, vs using the rewrite as an opportunity to experiment on the design and the implementation (and the language, and the ...).

Vetting a new design takes time, consensus, and subjective judgement. Re-implementing an existing design is laser focused and objective.

While people and organizational knowledge are important, I have to disagree with the article. Code has value, tremendous value in fact. It’s the only record of truth of a software product. The code of a working product records the decisions, the designs, solved problems and solved mistakes during the development. Software development is not just writing the code. The code is the end product of the development process which can be long and arduous. Yes. It can be reproduced with skill, time and money, but it can be prohibitively expensive. Thus lays the value of the code.

Edit: case in point, Sybase created the SQL Server. During one of the due diligence of business partnerships with Microsoft, Microsoft “borrowed” a copy of the source code (not sure about the details). After much legal wrangling, Sybase was forced to license it to Microsoft due to the loss of leverage. Microsoft released it as MS SQL Server. It took years and years of work for Microsoft to finally replace the code piece by piece.

I have a problem that I test new UI frameworks on; generating celtic knotwork. I've written three of these now (React, VueJS, and Go manipulating SVGs). The first was hard because I had to learn how to solve the problem. The others were hard because I had to learn how that solution changed because of the framework.

There's a joy in rewriting software, it is obviously better the second time around. As the author says, the mistakes become apparent in hindsight and only by throwing it all away can we really see how to do it better.

I also sketch (badly) and the same is true there; sketching the same scene multiple times is the easiest way of improving and getting better.

Another big piece I would add to this is the processes that enable organizations to ship code. Not just processes that are directly related to the product and code, but other organizational processes like hiring, sales, support, etc.

Efficient processes require a lot of thought to develop and implement. When a badly-run organization acquires a good piece of code, it will eventually start to stagnate and bloat.

The value is in keeping the code running. Unless you are doing something very complex from scratch, you are mostly writing code for hire or for your startup. Nowadays, that code does not really take that long to develop. You will be wrapping, mixing, and orchestrating several paid, free, and OSS APIs and frameworks to work together with your solution to the problem. This will take six to eighteen months to complete. Then the value starts. That code is making you or someone else money. If you stop efficiently and correctly managing the code, someone loses money.

Couple months back, someone posted how they lost a days work due to hard drive crash and had to redo it. It took them roughly 30 minutes.

Their point was the same as this article with a shorter time window. Knowing what to do, not how to do it, is 90% of the battle.

But that is counterintuitive to the lay observer of software. They think they know what to do, because they’ve got ideas, but feel inhibited because they don’t yet know how to achieve them. So they assume that their immediate hurdle must be the hard part of software development.

I mean code ages quickly, so the value of software must include the skillset needed to support and maintain it. Which is why enterprise software contracts exist, and are expensive. You're not paying for the binary. You're paying for the team supporting it.

I can say that in learning go several years ago, rewriting a ~10k LOC app that I had done in python, I definitely learnt some new paradigms in go that allowed me new perspective in what I had done in python.

I would have gone back to fix my python code, but I'm happy with the rewrite in go (runs faster, has far more test cases, which allowed me to add more functionality easier)

And yes, the rewrite took me ~50% of the time, and most of that was due to it being an exercise in learning go (including various go footguns).

A different perspective is that there is a vast body of result-of-thought-and-experience associated with developed software. That is then lossily encoded in many forms. Memory, judgment, skill, team, contacts, customers, docs, test suite, other assorted software, etc. It's much easier to reimplement a language when you have a great language test suite. Easier to create a product if you already have a close relationship with its customers. Easier to implement something for the 3rd, 4th, 10th time. Etc. And the assorted forms have results they encode well and not so much, and assorted strengths and weaknesses as mechanism. Memories decay, and aren't great for details. Judgment transfers well; leaves. Teams shuffle. Tests become friction. Software works; ossifies.

Insightful synthesis around even a single form isn't exactly common. The art of managing test suites for instance. An insightful synthesis of many forms... I've not yet seen.

I want to hear the perspective of someone who lost 100kloc and had to rewrite it all!

There is a lot of value in code. It works in prod. It is continuously regression tested by its load, so when there is a problem you figure out a tiny delta to fix it.

If you rewrite from memories you'll get a lot of bugs you need to fix again.

Code being worthless and "must keep PRs small" seem to be in tension.

> web portal I was involved in developing as part of an all remote team back just before the turn of the millennium. > I can conclude that of the 6 months of time spent by 7 people creating this solution, hardly any of it related to the code. It could be completely discarded and rebuilt by one person in under two weeks.

I bet he did it recently and that undermines his whole thesis. He would need to have redeveloped it before 2000, to support his argument. I would also suspect he only made a toy 80% working example and that it only needed the other 90% to be completed (e.g. administrative or developer focused features). I'm pattern matching with other developers I've heard say similar things.

Information that articles ignore is often critical; moreover we judge articles based on the meta-decision of "what critical information was ignored". The article severely misses some key points.

A better example that a developer is more valuable than the code: when a key member of a company goes off and greenfield develops a competitor that wins (but still not an independent measure due to confoundering effects).

In some situations I would agree with the thesis, but unfortunately the article poorly argues the point.

"Programming as Theory Building" 1985 by Peter Naur makes the same case and works out some of the implications. One of my favorite computer engineering papers.

https://pages.cs.wisc.edu/~remzi/Naur.pdf

Paper discussed multiple times on HN, notably:

https://news.ycombinator.com/item?id=10833278

> finally, there’s the code. That also takes time, but that time is small in comparison to all the others ... The developer’s answer to all of this is “refactoring”. For those of you who don’t code, refactoring is ... This takes time.

Yeah, please never manage a software team. Thanks.

Corollary: The value is in vibe coding. AKA - knowing how to prompt well.

We got bought out a number of years ago. We'd been pretty liberal with our code up until this point as I'm sure many tiny companies are, but our new owners were very insistent on locking down "Intellectual Property" to exclusivly company controlled hardware locked behind SSO ready to lock anyone out at a moments notice...

You are putting a pretty basic CRUD app in Fort Knox. We're not building anything super proprietary or patentable, it's not rocket science. Anyone could rebuild something roughly analogous to our app in a matter of weeks.

The code isn't the value. Our connections, contracts and content are our value. Our people and our know how is the value.

The code is almost worthless on its own. The time and thus money we've spent has been far more in finding and fine tuning the user experience than in "writing code". These are things exposed to anyone who uses our app.

You could genuinely email all our code to our direct competitor and it wouldn't help them at all.

> The design was in my head, and with hindsight I could see all its flaws. I was therefore able to create a much more efficient and effective design based on that learning. All the mistakes had been made, so I was able to get this version of the code right the first time.

I feel like you need to be careful with this. Ive seen a lot of times the rewrite ends up being more complicated then the original, even stuck in some rewrite hell and never takes off. I think its called the "2nd system effect"

Absolute nonsense. There is little division between the ideas and the code. Saying they're completely different isn't just myopic, it's dangerous.