EDIT: to the mods: maybe the link in the parent comment could be updated and my comment deleted? (I am the maintainer of cygale.net — the demo website can be edited by virtually anyone… my personal webpage is much more trustable).
Okay thanks. I will put a permanent redirect to inform GScholar's index of the actual stable URL of the document. Text selection and accessibility is indeed why I took the time to build this proper PDF as I explained here before seeing your comment: https://news.ycombinator.com/item?id=26035175
_My_ source code is invaluable. It's open, public, free to reuse under the GPL. It's a complete implementation of a painting application used by millions of people. It's a huge amount of knowledge readily accessible. You won't be able to buy something like this for any sum of money, so it's free.
Is it really the source code that has value, or your continued expansion and development of said code? Genuine question.
The reason I'm asking, while I was writing the article, I was considering including the youtube-dl fiasco (when the RIAA took it down from GitHub) as an example. People were concerned not because the code was gone (lots of mirrors popped up quickly), but because they were worried that the contributors would stop further development.
I think that's another indicator that the code itself carries little value. However, the problem space you've loaded and mapped to code in your own head, does have lots of value. Of course the fact that you're sharing it with the world in the best format we know so far (code) for free is much appreciated :)
A snapshot of source code can be useful as a basis for some other project. However, you're also correct that, if the source code is abandonware and you/others have no interest in maintaining it, it almost certainly becomes less useful over time and at some point just breaks.
Youtube-dl is an app chasing a moving operating of trying to interact with other sites APIs... many of which don't really even want to let youtube-dl do that. Most apps aren't in such a difficult space and keep working basically forever.
Even if the project is 'dead' it still runs, particularly on Windows.
I'm running the final release of Winamp as I type this. I organize my hard disk with the 1.0 of Spacemonger, which was free before it went paid. I edit audio files with Sound Forge 11 (up to 14 or so now) and before that I had a pirated copy of 6.0 that worked pretty well. I have a 'programs' folder full of stuff that runs without installation, some of which hasn't been touched in 5 or 10 years, and everything still runs when I try it.
You are my software twin. I'm using Winamp 2.95 this very moment, and Spacemonger 1.0 which still works fantastically. Both have slight crashes in rare edge cases now but perfectly usable day-to-day. You wouldn't perchance also be using an old version of UltraEdit before the heavy focus on subscriptions?
The last update to TeX (widely used in math and computer science for typesetting) was 12 January 2014.
A lot of payment processing systems are still running on code written in the 1960s and 1970s. Frequently untouched since Y2K.
I have a friend who went to work in the mid 2000s for a company she had worked for in the early 1970s. Out of curiosity she looked up her old programs. They were still running, unchanged. She asked why and was told, "They never broke."
One of the reasons for the survival of FORTRAN is that there are trusted software packages that people rely on which were written decades ago and still run.
There is an active emulator community for people who want to run games that are decades old, unchanged.
No, your old Netscape browser won't work in the modern web. Nor are early mobile apps going to run. But you'd be amazed at how many places you can find old software still happily running today.
Good modular design is helpful here. Properly segregating responsibilities means that portions of your code base can become "finished", while other portions remain in near constant flux. For an emulator, for example, if you separate the rendering from the hardware emulation portion, you can leave the hardware emulation portion untouched for years at a time while changing just the rendering code to port to new platforms.
The best "old" (30+ or 40+ years) code I worked on did this. The worst, which forced total rewrites, mingled everything together "for performance" but prevented the software from being easily ported to a new OS (Windows 3.1 hasn't been supported for a long time) or extended to support new capabilities.
Old version? You have to understand that some applications need innovation based on new ideas. TeX is only popular in the academic and publishing world, not like a web browser. Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word?
Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word?
Thank you for the most ludicrous comment that I've seen today. The popularity of TeX in academia is exactly because writing complex equations in popular word applications is painfully hard, and the typesetting is poor. By contrast writing them in TeX is easy and the typesetting defaults to excellent.
Talk to anyone who has to actually write many such equations. They will verify that it is not a question of "as easy". It is massively easier and better in TeX. Which is why academics working in math, physics and computer science overwhelmingly choose TeX.
Obviously depends on where along the learning curve, and preformed command
line literacy, which on a venue like HN is always assumed to be native.
As a hypothetical, consider a Rip Van Winkle situation in which a
mathematician wakes from a coma he's been in since the 1970s. Now force him
to typeset one of his monographs. He'll do it in MS Word.
Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native.
Actually not.
As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.
I have personal experience pertaining to this.
Before I was a programmer, I was a graduate student in mathematics. I wound up in the early 90s having never used Word or TeX and in a position where I needed to type up a paper. I began with Word, and before long I complained about how hard it was. A fellow grad student said I should learn how to do it in TeX.
It was literally faster, *on the very first paper that I tried to type*, to learn TeX and then type my paper in TeX than it was to try to do it in Word. The visual result was also massively better with TeX. Typesetting math formulas in Word is simply that bad.
I've tried to typeset some simple mathematics in Word since. The experience has not materially improved when it comes to typing real mathematics.
Based on this personal experience, I am quite confident that in the Rip Van Winkle situation that you describe, the mathematician will wind up doing it in TeX. And do it the same way that I did. Try Word because that seems easier. Ask a fellow mathematician when that proves to be a terrible experience. Be pointed at TeX and given a few tips. Discover that it is easier.
Okay, you win. Also: our individual opinions become vanishingly insignificant
relative to the aggregate opinion of the market, one that continues to pay for
MS Equation Editor.
Also: our individual opinions become vanishingly insignificant relative to the aggregate opinion of the market, one that continues to pay for MS Equation Editor.
Actually they don't.
People preferred paying for products like https://www.dessci.com/en/products/mathtype/ which allowed people to type TeX into Microsoft documents than they did Equation Editor. Therefore Microsoft gave up on Equation Editor. They then created an XML-based markup language for math, and MathBuilder around that. Which they then put a TeX translation layer into so that you can type simple TeX in Word, Outlook, and so on, then get a math equation out.
Sadly for Microsoft, they didn't actually remove Equation Editor. I say sadly because they eventually had to. Per https://securityboulevard.com/2018/01/microsoft-kills-old-of... it was found to have a serious security hole, and removing it was easier than fixing it.
Incidentally, despite having both TeX and MathML available to look at, Microsoft failed to turn out something as good as TeX for serious use. As a result most journals will not accept documents produced using Math Builder.
So the aggregate opinion of the market is in. TeX was better than MS Equation Editor. (Which is why TeX outlived MS Equation Editor.)
Ah, I see the "Equation Editor" moniker is now defunct. I've long been in the
LaTeX camp, so I've no idea what's transpired since 1990s when I last used
a quasi-wysiwig entry called "Equation Editor."
How you managed to conclude LaTeX entry is now more popular than whatever
quasi-wysiwig method MS Word currently supports is, I suppose, market
information I'm not privy to.
I wrote one. My point is, we need a better way to write a complex equation as easy as we wrote some texts like in MS Word or LibreOffice. That's an innovation. At least some guys in Microsoft or LibreOffice guys already did. Hide the complexity. Maybe one day you could write a complex equation only by voice command. No one will touch TeX anymore.
I think that's playing with semantics. Most codebases have old parts, the old part of texlive just has a name. It's still being actively maintained and would be a lot less usable if it wasn't, there's just an imaginary line between the texlive part and the tex part.
Your youtube-dl example doesn't make sense because youtube-dl wasn't wiped from everyone's computer nor from package managers nor from the internet. So of course losing youtube-dl wasn't the concern.
The thing at threat was the thing the team was using to maintain it, so that's what people were concerned about.
You don't care more about your garage than your house just because you're crying about your garage when a tornado wrecks it but not your house.
> You won't be able to buy something like this for any sum of money, so it's free.
I don't understand this. Why won't you be able to buy something like this? Do you mean you won't be able to sell it? I suppose if the first condition is true, the second condition follows.
I agreed with a lot of the points and that often source code might not be valuable but.... Much of it sounded like only thinking of a small team doing something no one else care about.
Conversely we have github and the millions of libraries it hosts in the form of source code.
We also have examples of WebKit based on KHTML, Blink based on that. Electron/Edge/Brave/Vivaldi based on Chromium. There is no one programmer who has the entirety of Chromium in their head and I'm pretty confident most teams would not find it easier to write their own browser from scratch. Chromium or WebKit are embedded in many places. PS5 and Oculus Quest are two off the top of my head.
I don't think that Naur was arguing that it has to be a single developer who knows everything. It could also be multiple developers, where each one of them has loaded a sub-problem of a bigger problem into their head.
Usually in OSS projects you have a handful or so of contributors doing the bulk of the work, right? Imagine them all going away at once for one of those projects you mentioned. I feel the project would be in pretty bad shape.
> But even Panic says in their blog post that they were not too concerned with competitors using their code either, mainly because it would quickly become outdated
And the legality bit? Big companies who aren't Uber know this isn't worth it, but even with smaller companies, if someone internally notices, the company could be in a lot of legal trouble. I haven't worked anywhere that would even consider using a competitor's code.
“One of the fears from management was that a big company like Google could take our code and build a competing service.”
Google, or any other respectable company, would not touch source code without a permissive license with a ten foot pole, least of all if it was retrieved as a result of improper access.
You can ask engineers that worked there about their processes. Google have extensive processes both for using external code and for engineers accessing user data. I worked for a while on a system that had some user data, and every single access was logged and reviewed to ensure that each data access was in response to a user filing an issue and only accessed the data needed to fix the users issue. That is a standard process implemented in all of Google.
Companies who doesn't have engineers talking about processes are therefore not trustworthy. Doesn't matter if it is due to them being too small to not have ex engineers, or them threatening their engineers into silence, or their engineers simply not caring about processes and therefore not talking. Never trust companies where only upper management makes statements about their processes.
Different company, maybe different problem, but importing code at Facebook was similarly difficult. The build issues were the least of it. More significant by far were the all-but mandatory requirements to integrate with the in-house deployment infrastructure, service discovery, background-task scheduling, metrics, logs, alerts, data structure libraries, RPC framework, etc. Your project already implemented some of those internally, or used open-source alternatives? Too bad. You could keep the core logic, but practically everything about how it connected to the rest of the world would have to be rewritten. Often, it just wasn't worth it, and a new "FB native" service reimplementing the same functionality was easier. If you didn't do it yourself, some other group would constantly be threatening to do it for you. It's hard to focus on code when you continually have to justify your project's very existence.
One problem I know -- different versions. They actually do have a small amount of third_party libs, but due to "diamond dependency" problem, they are accepting only only one single version of that dependency. And updating that dependency is a huge undertaking (even for small security bugfixes), so those libs are usually outdated.
Kinda similar to OS kernel organization: monolith vs. microkernel.
Is Google also out of engineers or something? I would imagine that the important thing about building a competing service isn't understanding the specific implementation, but seeing the value in what the service provides.
"Worthless" is an exaggeration: any significant body of code running a critical business process would be missed---and expensive to recreate---if it were lost. But I think the article does make a good point about the value to others. Unless you have a dev team whose head is in that code, and a business team built around that software workflow, just having the code won't be of much value to you. The value of software is inextricably linked to the team that has shaped it. So while it isn't worthless, it is certainly of much lower value without that team.
A better description would be "a liability". Every extra line of code is a line that has to be maintained in perpetuity. Each new engineer has to learn it all again.
The saleable product has value. A library you use for multiple products has some value. Everything else is cost.
Engineers are a liabity. You need them to write and fix code that runs your product, but other than that every extra engineer just demands salary and increases your costs.
Therefore I conclude that engineers have no value for a company, since when ignoring all the value they provide they just cost money.
It depends on size of the company. Cost is a relative instrument. Develop a big market product, highly demanding, or for a critical mission application is another story for "cost".
You are certainly correct about the costs of losing access to the source code, e.g., if it were destroyed.
However, it seems the author was discussing a different meaning of "lost", as in loss of control of the source and having it revealed to the outside world. He made the best arguments I've seen that the bulk of it is worthless to anyone else, who would be better off rolling their own from scratch, and provided a good example.
Indeed, if I were working a problem and somehow ethically came into possession of a competitor's code or product (e.g., via a buyout), the only use I'd put it to would be to try to see if they had any unique insights that we could adapt, and maybe some stand-alone chunks to use. And, indeed, that was the fate of a codebase of which I was quite proud when a company I co-founded got bought.
source code is excrement. an unfortunate side effect necessitated by the immaturity of our tools. someday we'll make software without it and life will be much better for the poo tenders.
I disagree. It’s the offloading of a decision space very carefully explored. Perhaps “language” and “syntax” can be generalized (ie “excrement”), but the ability to offload a decision space about how to react to a given scenario, without requiring someone to be actively thinking about the minutiae of the problem space, will always have value.
Whether that takes the form of a dependency graph in a software application or a set of assumptions (with their corresponding citations) in a scientific journal, the decision tree (inclusive of dependency graph) will always be essential.
I feel as though many problem spaces are already expressible in human language, but that “code” is just a more concise expression of the same thing.
The main issue with common language encoding is dialect (this happens in code, too, especially “common” languages like C++, Java, or JavaScript). That is to say, the assumptions you bring with you about what for example a “schedule” is affects all subsequent decisions based on it, but there are many possible interpretations for the semantics of such a thing.
It seems to me that most programming languages of today are better than “human language.” They more concisely AND precisely express the decision space.
I assumed “better tooling” meant some deeper heuristic wherein you might expect an AI to interpret your meaning based on your own enculturation, accepting the high subjectivity of any request/definition and producing an output formed by these assumptions.
I would still call this “source code” however, in much the same way that legal precedent is the source code for the next legal decision.
It is very often a developer perspective that the source code and the software product is the core delivery. Interestingly that is often not true. Customer care, project management, sales, marketing and so many roles contribute so much more to the value creation than often visible to a developer.
I completely agree, that's why I wrote in a footnote:
> However, I believe this statement is only true for software companies where the core technology is the main asset. For many software companies, the main value might not lie in their technology, but in other things, such as the network effects, relationships to customers, etc.
When I used to contract I used to work for a firm that would waste their time panicking about this but the reality was that their code was so bad that if it was released and their competitors could read it then that would probably help us because they'd be wasting their time. Much of it was _very_ hard to read, work with and needed serious improvements.
We don't sell the source code, we sell the ability to update, maintain, test and build that code and that's institutional and staff knowledge.
Source code of a large monolithic projects(Products) lacks value due not being adaptable or modular, but it has worth that can be decomposed and refactored into other software(libraries/packages/headers/functions).
I'll speak for all the ten-year vets who know stripping a monolith for parts is often as time-consuming as writing from scratch, and always uglier. Software is not a car.
You just need great archeologists to dig some worth out of source code whose authors have long past. At least, that's the premise behind Vernor Vinge's programmer archaeologists as portrayed in the fiction A Deepness in the Sky. Dystopian views of how code will evolve in the future are useful to informing on these kinds of things.
The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true.
In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates are working on applications which have 2-4 years of catching up to reach the same level of maturity as my existing work.
It's taken me the better part of a year to communicate the whys, whats, and hows of the systems we've built. I've given multiple talks, explained in 1:1s, written docs, and it's just taken a really long time to get across these ideas. All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.
Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.
It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful.
Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
Do you have any examples of sufficiently thorough documentation?
I've basically never been happy with the documentation I've been provided with, whether for internal company code or 3rd party OSS stuff or 3rd party paid stuff...
Just do audits. There are ISO standards for practically everything and you should run internal audits (and external ones if you can afford it for important stuff).
Reading and writing scale in theory. They require an organization staffed with people who are strong readers and writers. Unfortunately, many people, especially those forced into remote work during the pandemic, are not. They will not read through explicit, clear, but long documentation; they will not respond by writing questions of their own, and will often fail at writing explicit and clear documentation of their own.
Their job is not to write docs, it's to produce a product. The docs are a possible tool towards that goal, but there are others, with different trade-offs - such as in-person trainings.
It is fairly obvious that most of the industry believes the opposite from you here - thorough docs are an extremely expensive way of achieving good context, and as such are usually replaced with training sessions, which seem to fit most people better up to some point.
- The student has questions that it wouldn't have occurred to the teacher to answer.
- The student gets confused and asks for things to be rephrased or reframed.
- The student has questions that don't currently have static answers, but get computed by the teacher in real time, according to an intuition and assimilation of the facts that the student is only beginning to develop.
- The teacher's answers are up to date, whether or not he has actually exercised the diligence to maintain the textbook.
- The teacher fields the questions that the specific students ramping on the project actually have, rather than trying to anticipate all possible questions of all hypothetical students (and still failing).
There is a reason we have college and not just reading lists. And those are subjects where the economics support massive investments in discovering the best / most broadly useful ways to present the ideas. The average software project isn't that.
The commoditized software factory is an MBA fantasy. The expertise held by "key persons" is a software team's greatest asset.
Then you had poor teachers or a poor structure that didn't give you access to teachers in the right way.
While documentation has both advantages and disadvantages compared to in-person training, video tutorials are strictly worse than an interactive lecture.
I’m an autodidact. No teacher can provide the density and velocity of information and knowledge the Internet, science papers and books can provide. I can’t watch a lecture at 2x speed if its live. I can’t cherry pick. I have to be at a certain place at a certain time when I might not be in the right headspace. Then add on top that’s it’s basically a crapshoot whether or not you get along with your teacher or not. I don’t regret going to college but I didn’t gain much academic knowledge there either.
> I can’t watch a lecture at 2x speed if its live. I can’t cherry pick.
If you have a 1:1 teacher you can just tell them what you already know and they can jump to the parts you don't. Much more efficient than skipping through a video for interesting snippets.
100%. As an undergrad in the 90s I came to this conclusion as well. Then when YouTube, Khan Academy, and MOOCs hit critical mass in the 2010s, I could see the beginning of the end. COVID-19 has greatly accelerated the demise of in-person learning, and the fact that colleges continue to charge the same tuition is clear evidence that what they're selling isn't education, it's credentialling.
Unfortunately for me, I started developing really bad RSI around January of last year, and typing has been incredibly painful. In the past I would have discussed things using whiteboards, sitting down side-by-side with code, etc.; these are all very hard to do if typing causes pain.
Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a long time to unwind. Being able to gauge on-the-fly if the audience understands can save tons of time and confusion.
I've got 17 years of domain experience across 3 companies in the industry; there's no way I'm going to write all that down in my docs.
You're not wrong; I've actually thought about that.
Fortunately my RSI is starting to get better. Therapeutic massage and shoulder rehab exercises have made a big difference (I had a bike accident a few years back, and my shoulders were in pretty bad shape).
I stopped typing on my 2018 MacBook Pro's keyboard (which I think contributed to my problems), and exclusively use an ErgoDox. I've also been taking Magnesium as well as NSAIDs to reduce inflammation. Still a daily struggle, but I can type posts like this one without too much pain.
I think it should help in a way. But I also believe that people overestimate how well one can learn in depth about a complex problem from reading or any mainly passive activity alone.
I know there is this theory about learning styles but it's largely debunked.
To get a really solid understanding of a topic such as a business domain and it's interaction with a complex process and application, it takes a certain amount of time and contact with real problems. The only time that people can quickly pick up new ideas from reading is when they have mastered all of the underlying concepts of that knowledge. But applications generally have layers of very specific knowledge required to understand the problem and existing solution.
The point of the article I think is that it's usually going to take a significant amount of time for new developers to become familiar, regardless of how good the source or documentation is.
I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)
One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "random" manner rather easily in person.
At my workplace, we have a few blocks of time scattered around the schedule for teammates to just jump in and code with other people. No agenda, no one is required to join. But a few always do, because it's so pleasant.
It sounds like the new teammates are too comfortable if their current learning rate is 2-4 years. That number could also be an overestimation, which reinforces the relative rank in the team.
This points to another "field of tension": when the value of the company is in the minds of the programmers (not in the code), how should an organization handle rank such that all team members become stakeholders in the most effective progress?
I suspect more like academic rank rather than "team lead" or "lead dev".
My field, medical device software, has very long product cycles. It's not that my teammates are taking a long time to learn, it just takes time for a project to reach maturity.
Additionally, we've all been learning to collaborate in a new mode, with immense distractions. Prior to our reorg, we'd never actually worked together before. And we all had our own deadlines we were trying to meet. The last 11 months have been pretty awful, ya know?
> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.
This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so.
Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).
Working code (beyond super basic CRUD) that maintains a companies revenues is 'priceless' not 'worthless'.
It's 'worthless' to outside parties, but that's completely besides the point.
I worked at a Networking startup that made it's own ASICs and was sold for billions on the legit premise of 'working silicon'. The plans were actually stolen by a contractor who walked out, and while bad, were a little besides the point because they can't reasonably be used by others.
It's like saying 'GM's factory is worthless'. Well maybe on the free market, but as an operating entity it's worth a lot.
And yes, 'autonomy' is a nice thing for senior devs, but it's also hard to do in practice.
This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation
But it can be expressed in commit messages and "why" comments! This is very important a lot of developers don't understand and want to just "get on with their life" after writing the commit message "fix".
If used properly, version control can be the repository for all ideas stored historically and can be replayed. With well-written commit messages and well-formatted commits, whole ideas can be followed and mistakes can be recognized years after the code has been written. I have seen multiple times when we recognized "oh, they wanted to do this or that, but they forgot to change this", so we could fix it, because we understood the original idea someone had 10 years ago!
I believe, THE PRODUCT of Software Engineers work is not source code, but COMMIT MESSAGES!
"When we hired a new COO, who had mainly worked at bigger companies before, he was shocked to hear that all our code, communication infrastructure and internal systems were living in the cloud. He argued that we should move to on-premise solutions as soon as possible, partially out of fear of intellectual property theft, partially to appease investors with similar fears."
A team that needs 6 months to get their code running on a computer on-premise, might also be replaceable. Maybe the lesson is that that team that produces source code without value.
I appreciate a good catchy headline as much as the next person, but it's a ridiculous claim that "source code is worthless". On some level maybe it's not worth as much as some might make it out to be, but it's not worthless. There's a ton of strategic insight to be derived from the source code, not to mention just a basic time-value of money level of value.
If you accept the idea that programming is theory building, it's not that difficult to see when source code isn't worthless - when it's not the slow slog of building a theory entirely of well known facts, but when it contains leaps of insight.
There is also value in knowing which particular theories you're fleshing out vs. ignoring.
tldr: Code needs constant updating, and a coder who hadn't
originally wrote the code will almost certainly make distasteful and often
incorrect modifications. Ergo, code is worthless.
editorial: Most devs with >5 years experience know this. The digitization of
content made movies, music, books, and software all but financially worthless.
Split-second, error-free replication has rendered the IP of so-called
"knowledge workers" far less valuable (movie studios, recording labels,
newspapers, programmers).
Provocative, exaggerated title but a great article.
I would argue that many bodies of source code are worth something even if they were handed to me without any additional info. Let's say I'm working with a new microcontroller and someone gives me the source to a TCP/IP stack for that new micro. From the data sheet of the micro I could make sense of the lower levels of the stack and TCP/IP is so well defined that just the value of someone making it work on the particular hardware, which is mostly busywork, has huge value.
I agree with the conclusions, but the premise that “source code is worthless” is click-baity and misleading.
After having gone through a few M&A discussions with a high-tech software startup this is how I think about it: Nobody wants to buy just the source code. Talent / team that is used to work together and has proven itself has some value (i.e. “talent acquisition”), but valuation won’t be very high. What’s really valuable is talent and code (with IPR rights) combined.
But don’t think you can put the source code on GitHub under an MIT license and it won’t affect your M&A discussion... ;)
This is startup-centric and depends heavily on the velocity of your project. For intrinsically difficult problems that evolve slowly or not at all (the most extreme example of this would be e.g. unsolved CS problems), source code is gold and its theft represents a huge blow to any competitive advantage a product might have had. Note that this is different from saying the source code itself doesn't evolve.
For problems whose difficulty relies rather on business concerns and which evolve rapidly then (the theft of) source code is nearly worthless.
197 comments
[ 3.2 ms ] story [ 223 ms ] thread[Programming as Theory Building -- Naur 1985] https://demo.cygale.net/naur1985programming.pdf
This demo website might disappear or at least the pdf might be removed from it. The stable version of this PDF is on my web page here: https://pablo.rauzy.name/dev/naur1985programming.pdf
EDIT: to the mods: maybe the link in the parent comment could be updated and my comment deleted? (I am the maintainer of cygale.net — the demo website can be edited by virtually anyone… my personal webpage is much more trustable).
I was looking for a version of the paper with machine-selectable text (because the PDF linked in the OP is a scan with no OCR).
The reason I'm asking, while I was writing the article, I was considering including the youtube-dl fiasco (when the RIAA took it down from GitHub) as an example. People were concerned not because the code was gone (lots of mirrors popped up quickly), but because they were worried that the contributors would stop further development.
I think that's another indicator that the code itself carries little value. However, the problem space you've loaded and mapped to code in your own head, does have lots of value. Of course the fact that you're sharing it with the world in the best format we know so far (code) for free is much appreciated :)
A snapshot of source code can be useful as a basis for some other project. However, you're also correct that, if the source code is abandonware and you/others have no interest in maintaining it, it almost certainly becomes less useful over time and at some point just breaks.
Sadly, this doesn't match my experience. Software that isn't actively maintained always dies, sooner or later.
I'm running the final release of Winamp as I type this. I organize my hard disk with the 1.0 of Spacemonger, which was free before it went paid. I edit audio files with Sound Forge 11 (up to 14 or so now) and before that I had a pirated copy of 6.0 that worked pretty well. I have a 'programs' folder full of stuff that runs without installation, some of which hasn't been touched in 5 or 10 years, and everything still runs when I try it.
Code is eternal.
Especially win32 apps, thanks both to windows and wine
> Even if the project is 'dead' it still runs, particularly on Windows.
For software I want to run long term, I always get the win32 version.
I personally hold the opinion that if the project is not being maintained, giving away the source code allows someone else to pick it up.
[0] http://vina.scripps.edu/download.html
The last update to TeX (widely used in math and computer science for typesetting) was 12 January 2014.
A lot of payment processing systems are still running on code written in the 1960s and 1970s. Frequently untouched since Y2K.
I have a friend who went to work in the mid 2000s for a company she had worked for in the early 1970s. Out of curiosity she looked up her old programs. They were still running, unchanged. She asked why and was told, "They never broke."
One of the reasons for the survival of FORTRAN is that there are trusted software packages that people rely on which were written decades ago and still run.
There is an active emulator community for people who want to run games that are decades old, unchanged.
No, your old Netscape browser won't work in the modern web. Nor are early mobile apps going to run. But you'd be amazed at how many places you can find old software still happily running today.
The best "old" (30+ or 40+ years) code I worked on did this. The worst, which forced total rewrites, mingled everything together "for performance" but prevented the software from being easily ported to a new OS (Windows 3.1 hasn't been supported for a long time) or extended to support new capabilities.
But if you want to actually use it you'll install a much more recent distribution - probably texlive from 2020.
But the heart of it, TeX, is still the same old version.
Thank you for the most ludicrous comment that I've seen today. The popularity of TeX in academia is exactly because writing complex equations in popular word applications is painfully hard, and the typesetting is poor. By contrast writing them in TeX is easy and the typesetting defaults to excellent.
Talk to anyone who has to actually write many such equations. They will verify that it is not a question of "as easy". It is massively easier and better in TeX. Which is why academics working in math, physics and computer science overwhelmingly choose TeX.
Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native.
As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.
Actually not.
As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.
I have personal experience pertaining to this.
Before I was a programmer, I was a graduate student in mathematics. I wound up in the early 90s having never used Word or TeX and in a position where I needed to type up a paper. I began with Word, and before long I complained about how hard it was. A fellow grad student said I should learn how to do it in TeX.
It was literally faster, *on the very first paper that I tried to type*, to learn TeX and then type my paper in TeX than it was to try to do it in Word. The visual result was also massively better with TeX. Typesetting math formulas in Word is simply that bad.
I've tried to typeset some simple mathematics in Word since. The experience has not materially improved when it comes to typing real mathematics.
Based on this personal experience, I am quite confident that in the Rip Van Winkle situation that you describe, the mathematician will wind up doing it in TeX. And do it the same way that I did. Try Word because that seems easier. Ask a fellow mathematician when that proves to be a terrible experience. Be pointed at TeX and given a few tips. Discover that it is easier.
Actually they don't.
People preferred paying for products like https://www.dessci.com/en/products/mathtype/ which allowed people to type TeX into Microsoft documents than they did Equation Editor. Therefore Microsoft gave up on Equation Editor. They then created an XML-based markup language for math, and MathBuilder around that. Which they then put a TeX translation layer into so that you can type simple TeX in Word, Outlook, and so on, then get a math equation out.
Sadly for Microsoft, they didn't actually remove Equation Editor. I say sadly because they eventually had to. Per https://securityboulevard.com/2018/01/microsoft-kills-old-of... it was found to have a serious security hole, and removing it was easier than fixing it.
Incidentally, despite having both TeX and MathML available to look at, Microsoft failed to turn out something as good as TeX for serious use. As a result most journals will not accept documents produced using Math Builder.
So the aggregate opinion of the market is in. TeX was better than MS Equation Editor. (Which is why TeX outlived MS Equation Editor.)
How you managed to conclude LaTeX entry is now more popular than whatever quasi-wysiwig method MS Word currently supports is, I suppose, market information I'm not privy to.
The thing at threat was the thing the team was using to maintain it, so that's what people were concerned about.
You don't care more about your garage than your house just because you're crying about your garage when a tornado wrecks it but not your house.
[0] https://krita.org
I don't understand this. Why won't you be able to buy something like this? Do you mean you won't be able to sell it? I suppose if the first condition is true, the second condition follows.
Conversely we have github and the millions of libraries it hosts in the form of source code.
We also have examples of WebKit based on KHTML, Blink based on that. Electron/Edge/Brave/Vivaldi based on Chromium. There is no one programmer who has the entirety of Chromium in their head and I'm pretty confident most teams would not find it easier to write their own browser from scratch. Chromium or WebKit are embedded in many places. PS5 and Oculus Quest are two off the top of my head.
Usually in OSS projects you have a handful or so of contributors doing the bulk of the work, right? Imagine them all going away at once for one of those projects you mentioned. I feel the project would be in pretty bad shape.
And the legality bit? Big companies who aren't Uber know this isn't worth it, but even with smaller companies, if someone internally notices, the company could be in a lot of legal trouble. I haven't worked anywhere that would even consider using a competitor's code.
Google, or any other respectable company, would not touch source code without a permissive license with a ten foot pole, least of all if it was retrieved as a result of improper access.
Companies who doesn't have engineers talking about processes are therefore not trustworthy. Doesn't matter if it is due to them being too small to not have ex engineers, or them threatening their engineers into silence, or their engineers simply not caring about processes and therefore not talking. Never trust companies where only upper management makes statements about their processes.
1. They have monorepo with custom build infra, which makes integrating any third_party code pretty hard.
2. In google career culture, one gets promoted for development of something new, not integrating existing proved solutions.
Why would it be significantly harder than creating new project?
Kinda similar to OS kernel organization: monolith vs. microkernel.
The saleable product has value. A library you use for multiple products has some value. Everything else is cost.
Therefore I conclude that engineers have no value for a company, since when ignoring all the value they provide they just cost money.
However, it seems the author was discussing a different meaning of "lost", as in loss of control of the source and having it revealed to the outside world. He made the best arguments I've seen that the bulk of it is worthless to anyone else, who would be better off rolling their own from scratch, and provided a good example.
Indeed, if I were working a problem and somehow ethically came into possession of a competitor's code or product (e.g., via a buyout), the only use I'd put it to would be to try to see if they had any unique insights that we could adapt, and maybe some stand-alone chunks to use. And, indeed, that was the fate of a codebase of which I was quite proud when a company I co-founded got bought.
Whether that takes the form of a dependency graph in a software application or a set of assumptions (with their corresponding citations) in a scientific journal, the decision tree (inclusive of dependency graph) will always be essential.
The main issue with common language encoding is dialect (this happens in code, too, especially “common” languages like C++, Java, or JavaScript). That is to say, the assumptions you bring with you about what for example a “schedule” is affects all subsequent decisions based on it, but there are many possible interpretations for the semantics of such a thing.
It seems to me that most programming languages of today are better than “human language.” They more concisely AND precisely express the decision space.
I assumed “better tooling” meant some deeper heuristic wherein you might expect an AI to interpret your meaning based on your own enculturation, accepting the high subjectivity of any request/definition and producing an output formed by these assumptions.
I would still call this “source code” however, in much the same way that legal precedent is the source code for the next legal decision.
> However, I believe this statement is only true for software companies where the core technology is the main asset. For many software companies, the main value might not lie in their technology, but in other things, such as the network effects, relationships to customers, etc.
We don't sell the source code, we sell the ability to update, maintain, test and build that code and that's institutional and staff knowledge.
In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates are working on applications which have 2-4 years of catching up to reach the same level of maturity as my existing work.
It's taken me the better part of a year to communicate the whys, whats, and hows of the systems we've built. I've given multiple talks, explained in 1:1s, written docs, and it's just taken a really long time to get across these ideas. All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.
That is my experience at least (even in very well documented projects).
Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
I've basically never been happy with the documentation I've been provided with, whether for internal company code or 3rd party OSS stuff or 3rd party paid stuff...
You are who you hire.
It is fairly obvious that most of the industry believes the opposite from you here - thorough docs are an extremely expensive way of achieving good context, and as such are usually replaced with training sessions, which seem to fit most people better up to some point.
- The student has questions that it wouldn't have occurred to the teacher to answer.
- The student gets confused and asks for things to be rephrased or reframed.
- The student has questions that don't currently have static answers, but get computed by the teacher in real time, according to an intuition and assimilation of the facts that the student is only beginning to develop.
- The teacher's answers are up to date, whether or not he has actually exercised the diligence to maintain the textbook.
- The teacher fields the questions that the specific students ramping on the project actually have, rather than trying to anticipate all possible questions of all hypothetical students (and still failing).
There is a reason we have college and not just reading lists. And those are subjects where the economics support massive investments in discovering the best / most broadly useful ways to present the ideas. The average software project isn't that.
The commoditized software factory is an MBA fantasy. The expertise held by "key persons" is a software team's greatest asset.
While documentation has both advantages and disadvantages compared to in-person training, video tutorials are strictly worse than an interactive lecture.
If you have a 1:1 teacher you can just tell them what you already know and they can jump to the parts you don't. Much more efficient than skipping through a video for interesting snippets.
Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a long time to unwind. Being able to gauge on-the-fly if the audience understands can save tons of time and confusion.
I've got 17 years of domain experience across 3 companies in the industry; there's no way I'm going to write all that down in my docs.
There are also voice coding solutions like Talon voice that work well (I use it regularly).
Has worked for many, me included.
Fortunately my RSI is starting to get better. Therapeutic massage and shoulder rehab exercises have made a big difference (I had a bike accident a few years back, and my shoulders were in pretty bad shape).
I stopped typing on my 2018 MacBook Pro's keyboard (which I think contributed to my problems), and exclusively use an ErgoDox. I've also been taking Magnesium as well as NSAIDs to reduce inflammation. Still a daily struggle, but I can type posts like this one without too much pain.
I know there is this theory about learning styles but it's largely debunked.
To get a really solid understanding of a topic such as a business domain and it's interaction with a complex process and application, it takes a certain amount of time and contact with real problems. The only time that people can quickly pick up new ideas from reading is when they have mastered all of the underlying concepts of that knowledge. But applications generally have layers of very specific knowledge required to understand the problem and existing solution.
The point of the article I think is that it's usually going to take a significant amount of time for new developers to become familiar, regardless of how good the source or documentation is.
It doesn't have to be that way, but if that's new to you and your team, I can understand that happening
This points to another "field of tension": when the value of the company is in the minds of the programmers (not in the code), how should an organization handle rank such that all team members become stakeholders in the most effective progress?
I suspect more like academic rank rather than "team lead" or "lead dev".
Additionally, we've all been learning to collaborate in a new mode, with immense distractions. Prior to our reorg, we'd never actually worked together before. And we all had our own deadlines we were trying to meet. The last 11 months have been pretty awful, ya know?
This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so.
Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).
It's 'worthless' to outside parties, but that's completely besides the point.
I worked at a Networking startup that made it's own ASICs and was sold for billions on the legit premise of 'working silicon'. The plans were actually stolen by a contractor who walked out, and while bad, were a little besides the point because they can't reasonably be used by others.
It's like saying 'GM's factory is worthless'. Well maybe on the free market, but as an operating entity it's worth a lot.
And yes, 'autonomy' is a nice thing for senior devs, but it's also hard to do in practice.
If used properly, version control can be the repository for all ideas stored historically and can be replayed. With well-written commit messages and well-formatted commits, whole ideas can be followed and mistakes can be recognized years after the code has been written. I have seen multiple times when we recognized "oh, they wanted to do this or that, but they forgot to change this", so we could fix it, because we understood the original idea someone had 10 years ago!
I believe, THE PRODUCT of Software Engineers work is not source code, but COMMIT MESSAGES!
While the analogy might not be perfect, it's kind of like trying to teach someone how to play the piano by asking them to read a book.
[shudder]
There is also value in knowing which particular theories you're fleshing out vs. ignoring.
editorial: Most devs with >5 years experience know this. The digitization of content made movies, music, books, and software all but financially worthless. Split-second, error-free replication has rendered the IP of so-called "knowledge workers" far less valuable (movie studios, recording labels, newspapers, programmers).
I would argue that many bodies of source code are worth something even if they were handed to me without any additional info. Let's say I'm working with a new microcontroller and someone gives me the source to a TCP/IP stack for that new micro. From the data sheet of the micro I could make sense of the lower levels of the stack and TCP/IP is so well defined that just the value of someone making it work on the particular hardware, which is mostly busywork, has huge value.
After having gone through a few M&A discussions with a high-tech software startup this is how I think about it: Nobody wants to buy just the source code. Talent / team that is used to work together and has proven itself has some value (i.e. “talent acquisition”), but valuation won’t be very high. What’s really valuable is talent and code (with IPR rights) combined.
But don’t think you can put the source code on GitHub under an MIT license and it won’t affect your M&A discussion... ;)
It still has to be written first.
For problems whose difficulty relies rather on business concerns and which evolve rapidly then (the theft of) source code is nearly worthless.