Peter Naur's view of programming
hiringengineersbook.com
hiringengineersbook.com
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).
That said:
If you are reading this comment and haven’t read the article, go read the article instead.
This is an inverse scenario: imho most of the comments here are interesting but have only marginal value building from the insight of the article.
ie., a Bank maybe finds most of its value in that its code runs, etc.
A software company, perhaps, we could define (1) simply as any company where this is true; or if that's cheating, (2) any company where its competitive advantage derives from its software developing over time.
I think the claim of this article is that (1) and (2) refer, aproximately, to the same companies: ie., that software which is changed to adapt to ever changing needs derives that capacity from the "theory of the programmers" and not the code.
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.
For most companies I'm familiar with, switching jobs (usually to a different company) is the most effective (and often the only) path to achieving a significant raise or promotion without moving into management.
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.
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.
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.
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... ;)
[shudder]
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.
However my pay wasn’t going up by much. I left for a new company and I feel like a noob having to re-learn things. It’s prolly going to take me an year to produce more value than I get paid.
Old company prolly had to replace me and spend 200k*2 years to get same context.
Very few companies understand the essence behind retaining good people. Promoting can be wayyy cheaper than having to hire someone new.
It really pisses me off when this happens to female and minority engineers. They frequently get looked down upon and left out for well deserved promos.
If you care about diversity, retain and grow your existing team. It’s cheaper and faster.
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.
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.
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.
Meanwhile, I think organisations underestimate the cost of attempting to keep source code secret. It adds friction to almost every step of the development process, compared to not worrying about whether your build logs or repositories are publicly accessible, even if they're not open source.
Shortly after NewCEO was hired, we had an all-hands introduction meeting. "All hands" at this point meant about 50 people, so our largest conference room was packed. I ended up sitting on the floor by the big whiteboard, opposite NewCEO. He started talking about how bigger companies were (he believed) actively trying to reverse-engineer our product. Without exactly meaning to, I said "good luck" loudly enough to get his attention, so he looked at me expectantly.
"We're having enough trouble engineering it forwards."
A few people laughed. NewCEO kind of glared. I guess I should mention that I was the product architect BTW. We never particularly got along, but he was neither the first nor the last CEO I outlasted during my career so meh.
Getting back to the point, maybe a competitor who had access to our code might, with great difficulty, learn something about the problem domain we were exploring (continuous data protection). More likely they would have been misled by all the remnants of wrong turns we'd taken during the exploration process. They'd literally be better off without it. Our entire business was a gamble that we could get to market before bigger competitors woke up to the opportunity and threw more bodies/dollars at it. As it turns out, that's exactly what did happen. We lost the bet. Other people having our code would not have changed that outcome one bit.
For problems whose difficulty relies rather on business concerns and which evolve rapidly then (the theft of) source code is nearly worthless.
It's not uncommon to hear the phrase used as a pejorative, with the implicit assumption that oral culture is inferior to literate culture and that tribalism == primitivism == bad and undesirable.
But I've come to believe that there are always going to be things that cannot or should not be represented in written documentation. Documentation is an artifact that must be maintained. Individual professionals and organizations spend a huge amount of energy producing, managing, and maintaining written documentation.
But how much time have we spent on oral transmission of ideas? Almost none. And that's because we dismiss it as an approach. It's seen as less than or primitive, or at best something to discourage.
But if you accept that there must always be some oral information, then ignoring the issues of how we communicate, update, and persist that orally transmitted information seems foolish. There are cultures that have more recently made the the transition from being primarily oral to literal that have not forgotten the skills needed to manage this class of knowledge.
I wonder what practices we can learn from them that we can use to improve our ability to share and communicate more effectively.
Reminded me a bit of Jon Blow's excellent talk here: https://www.youtube.com/watch?v=pW-SOdj4Kkk
Do you have any resources you can recommend on this topic?
Really I'm wondering where the divide is between, "you need to talk with me to learn this", and, "you can subscribe to my channel to learn this."
Vice versa, we're now contributing to the literal culture by discussion and people have been writing replies to texts forever. However, the ratio of information read to the amount of information discussed is different. It's harder to find people willing to discuss in writing a random piece of text you just read as opposed to discussing verbally what the lector just said.
It would be really hard to convince MS/Google/apple/etc that their primary products source code doesn't have any value.
I think there's some truth that code has value, and there is some risk that making it available can cut into profits (See: Redis, Mongo, etc, changing course after open offerings became available on AWS/Azure/GCP).
But I think the much larger truth is that most of the value provided by companies (and most of what they charge for) is not "lines of excellent code" but rather the operating expertise of keeping a complicated system stable and available.
For example - All of the companies you listed do have widely available, open source offerings (Android, VS-Code, Mono, Swift, Webkit, etc).
The value wasn't in the code, the value was in the ecosystem around it.
I think this is true in more cases than folks expect. The Windows source code was leaked, but I don't see any companies scrambling to compete with MS by building on that code.
I think even if most of Google's repo was made public - the valuable part was the team that supports the infrastructure behind it, not the lines of code themselves (or at least, they make up a smaller portion of the value)
If they opened that code, or apple opened up the entire iOS stack its quite likely they would have competitors that as you point out lowered the value of their primary offerings.
A google with a half dozen competent ad/search companies would look very different than the one that can afford to give away a large part of their product portfolio.
So, there is value in operating a "service" buisness, but there is even more value in operating a service business that has high barriers to entry. One way to erect those barriers is with hundreds of millions of dollars in engineering time spent on "source code" be that the code actually doing the searches/etc or the code being used to manage the clusters its running on.
An example like that is only valid if you argue that there was a reasonable chance that the company could have 1) developed a comparable closed source version of the product and 2) somehow prevented a competitive open source version of that product from existing and being used by competitors.
I guess before everything sync'd and auth'd to the cloud I could pirate Photoshop, but as the author points out, cracked software has always been a different landscape that carries malware more often than not and has no stability or feature updates, so why worry, it's no real competition if you're actually innovating your product, not to mention tech support!
As for throwing out code, I'd have to do some digging but there's a talk, maybe Dan Geer, outlining that every 1000 lines of code you write there's a certain number of security vulnerabilities, and you'll never find them all -- and the longer the code stays the same the longer those vulnerabilities are able to be prodded and discovered. So say you have an adversary with access to your source code, they are trying to figure out the "weird machine" of all the bugs in your code. The best way to foil this adversary is to keep changing the way your software works, always switching out one set of undetected bugs for another. Again, having a development team that understands how to change the code is infinitely more valuable than having access to the repo.
And the security argument is a strange one. If you never let the code "mature" then your defect count remains high. Which means there are likely exploits that can be quickly found with simple automated tools, vs being hardened enough that it actually takes real effort to find the ever more obscure cases. Which is why when you look at windows, a lot of the exploits recently are because they churned pieces of the OS that were decades old. And the "unsupported" versions of the OS weren't vulnerable. Similarly, the product I was working on a few years back dodged heartblead for the same reason. We were on a fairly old version of SSL only being patched with security updates. So, when the exploit finally became public we didn't have anything to worry about. Our version of SSL simply wasn't affected.
Its very dangerous to think that the most secure version of a product is the one that isn't battle tested because its being churned. That is just a reformation of the security through obscurity argument and assumes there aren't blackhats more than happy to hack a product and keep quiet about an exploit for years. Combined with the fact that now your hoping to randomly close these exploits through code churn just screams of a naive development model.
(comment on network effects)
I've rarely heard anyone mention any of the recent web based "innovation" as a reason to use photoshop over gimp, or even older versions of photoshop. OTOH, when I heard these discussions in the past, there were real hard reasons people didn't use gimp (color profiles?), libreoffice (document compatibility), etc. So the "innovation" needs to be something the end user finds useful, not just pretty buttons, or software subscription models.
Its obviously not enough to just appear to be a clone, there have to be real reasons to consider an alternative to overcome the network effects. When that happens you can bet people start choosing the "clone", which does in fact devalue the original offering. If a legitimate facebook , O365, etc competitor shows up you can bet people will start to switch even with the network effects of those two products. In the case of photoshop, from what i've heard a lot of people have been looking at Affinity's product. Which points to gimp still not being a proper alternative.
This isn't just software, its everything. Everyone keeps buying x86, until the day it turns out there is a cheaper/faster arm laptop. And it might not even be a change in the products themselves, the US automakers lost out in the 1970's because the market changed and they weren't as well positioned for it.
I would also argue that rewriting your code somewhat frequently is part of good engineering. As you discover more of the problem, old code needs to be discarded. Usually what happens is that you start solving problem A, then realize a new need to solve problem B. But really it would've been much better to solve a combination of the two, problem C, which requires an entirely different approach than dumping new code for B onto the old codebase for A.
It's actually part of why I wrote the article, because I do honestly believe it is a common misconception that rewrites are more expensive than modifications (although I'm sure that's true in some cases).
Also, I gotta say, while I appreciate that you took time to comment and chime in with the discussion, the way you worded it was quite rude and a bit hurtful.
You probably just hit some nerve of the person you responded to. Granted, your article was exaggerating about the worthlessness of source code, you made a very good and interesting point grounded in real experience.
On top of that you did something that I think is very important, commendable and interesting: Looking at the history of software engineering and programming. There is a wealth of knowledge and insights at our fingertips and as a culture we're not paying enough attention to history.
And the message is very sound if not taken to the extreme. Source code quality matters and is worth investing in, but people ultimately matter more. It's an important message that needs to be heard again and again.
[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).
I've certainly rebuilt something from scratch only to immediately stub my toe.
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.
The title of the article is How to hire senior developers: Give them more autonomy and it's not about Peter Naur's view of programming, it's about the author's view on how to hire senior developers.
The article has a few select quotes from Peter Naur's article "Programming as theory building" but the quotes are mainly used to advance the article author's opinions on hiring senior developers, rather than Peter Naur's idea of what programming is. Peter Naur does not seem to be related to this article or its author at all.
> One of Naur’s main conclusions is that making changes to an existing program (to accommodate changing requirements) is often more costly than writing new code from scratch, at least if done by people from a different team. 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:
Small, single purpose applications require less maintenance (which is expensive), but proper design allows them to be combined to create more complicated programs.
Do you build slightly larger tools that integrate the small tools? Even these larger tools my need to be composed into another level of abstraction to build the final system.
This is essentially the same architecture that you would build with a layered set of abstractions and interfaces.
It's really just a matter of how the different bits communicate that is different.
This disregards the effect of having users. Once you have built something and lots of people start using it then the code for the library becomes the main source of truth for what that library should do, since any changes to its behaviour is likely to break someone's workflow.
This is why making "clean rewrites" is so hard, since reimplementing all the peculiar behaviour of the previous implementation is much much harder than implementing new peculiar behaviour for a new library with less well defined requirements.
Source code isn't particularly useful for competitors, no, but it is extremely valuable for your company.
I recommend reading this paper to all my computer science students.
I took the liberty to make a better formatted and easier to read PDF of it a while ago: https://pablo.rauzy.name/dev/naur1985programming.pdf
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.
Good source code includes level of intent comments, it explains the reasoning behind decisions (especially the tradeoffs that were made) and warns future readers of potential pitfalls.
In both a professional setting as well as when wanting to contribute to a favorite OSS project, few things are more frustrating than jumping into the code only to realize it's missing this type of info.
And richly documented code is non-virtually worthless.
If you don't believe me, try parsing one of these so-called "literate programs." Any 10-year vet will far more quickly grok a piece of code when its textual flow isn't disrupted by verbiage that only makes sense to its author.
Obviously source code is useful on its face, and its also the truest documentation of current requirements. Worthless is an overstatement.
I've been part of a half dozen or so successful medium->large scale projects, and we never really deleted large parts of the code base. The small teams bootstrapping them had a pretty clear goals of where they were going sufficiently to build a reasonable scafold early on to get somewhat working prototypes. Then as the project took shape things were fleshed or refactored far more than they were thrown away.
OTOH, projects i've seen fail frequently had core pieces rewritten on a somewhat regular basis.
Which if you think about it in the sense that every time a chunk of code is wholesale replaced, that is X man hours of effort flushed down the toilet. Few startups can afford engineers to be working on things which don't go towards the bottom line.
AKA if you have 6 engineers, and on average are replacing 25% of the code base a year, that is the equivalent of just throwing away 25+% of your runway every year. With the team communications overhead/etc I could totally see that it might be possible to never actually make forward progress even though the amount of code being thrown away isn't >50%
If everything you write has to be "perfect" the first time around, you'll write a fraction as much as if you're willing to build 3 things (either now, or in the future), and take whichever works out the best. It might take more time, or it might take less time.
At the liquidation, the entire body of code from the two years was auctioned for $1372 to one of the founders. Chances are, if he had not bid, it would have been abandoned entirely. I doubt he looked at it, after.
For example, someone I used to know would always say that while the Linux kernel as a product (a free and open source operating system) is priceless, the source itself is worthless unless you have an understanding of its internals, and I think that this is generally true for codebases of similar size and complexity, although I'd argue Linux specifically doesn't fall into this area only because of the fact that drivers make up most of the code in it.
Stability is especially important when considering long term worth of code. When youtube-dl was removed from GitHub not too long ago, people were worried that the project would stop being updated and maintained, despite the fact that mirrors of the source code were everywhere. In that case, because the project needs constant updating and maintaining to keep up with websites like YouTube who have no incentive to continue to keep a stable API for downloading videos.
1) using source code to find security exploits
2) competitive machine learning algorithms
In the second case, imagine if a competitor had access to algorithms used in marketing for bidding on ads. You know what features it uses, what default values it uses, how it works, etc. You could do some damage with that knowledge
Often the customer's proprietary code is a small fraction of all the code.
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
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.
There is also value in knowing which particular theories you're fleshing out vs. ignoring.
I posit if everyone was automatically build able and deployable (say with Nix) across the board. Source code would have more value.
Now, it still would be true that less source code is better than more source code, so line by line / marginally source code is a liability. But reproducible functionality would be valuable.
The remaining worthless might have to do with much especially b2b proprietary software being utter crap, and all the value being in the sales relationship and none in product/service being traded.
Programmers say their job is to put themselves out of their jobs. People don’t want to be out of their jobs, really. And we know that doesn’t happen. If anything, it locks them into their job, as “subject matter experts”.
Also, most applications are built on a million layers of reusable abstractions. Even in the highest level of the code people are using frameworks and other libraries. A lot of source code is just business logic and glue code when you remove the stuff it is built upon, which tends to be much better (and many times, open and free).
I agree it is a fools errand to ask people to work against their incentives, but by https://en.wikipedia.org/wiki/Jevons_paradox I don't think there is actually disincentive given enough risk tolerance to let the new equilibrium emerge. Write better programs, and increasing the demand for programming.
I think the bigger problems is most programs are bad and alienated. Programming with everything nicely packaged and ready to be modified is like working with a clean workbench / shop. If you've never been in a clean one, cleaning seems like a chore, but if you have, working in a dirty one seems not only inefficient, but gross and undignified.
It's "take care of your tools, and your tools take care of you" vs being "lord of my garbage heap of tech debt". Any self-respecting craftsperson should choose the former.
You hit the nail on the head here.
I've worked a bunch of different jobs since college.
I have worked in exactly one clean, mature codebase.
The difference to all the others I've been in was like night and day.
I think seeing even "acceptably decent" code is incredibly rare in our industry.
To be fair, that's probably in large part because producing acceptably decent code is prohibitively expensive for any new product, and once you've gotten a new product off the ground and producing value, you've set the cultural norm that crappy code is what we make here.
I don't buy that, if I wanted to create a $HIGHDOLLAR application, and It was possible to get away with stealing the source code i'm sure it would happen more frequently.
Its not that the code for windows/etc is worthless, its that anyone attempting to make any money selling a clone that was obviously based on it would be put out of business.
If OTOH, they sold a license to resell products based on the XP64 code base you can bet there would be LTS/embedded/etc type companies pooping up selling their own versions.
So while the effort to get a functioning build system and learn the code base is considerable, its a lot easier than reinventing the wheel. Hence why the code _DOES_ have value.
The purpose of the code is as much to communicate with other humans as it is to communicate with computers.
They might use your code as a reference, especially from any research components of the project.
You'd be surprised what automated analysis of gitlab repos bring to light.
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.
Or in other words: building in business logic is paramount and the only thing you should be doing if running a startup, otherwise these engineers are just dossing around with code that doesn't yield a profit.
Is ElasticSearch (the company) then just a "bad business model"? Won't Google suffer if Amazon just waits for them to release their code and turns it into a managed service in competition? (Both companies are eminently capable here).
Why not patent?
No worries, not trying to sell anything (other than the book), just always curious what challenges people are facing when hiring.
> 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.
- There's only research programming
It still has to be written first.
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).
Edit: The submitted title was "Your source code is worthless". I've changed it now.
If anyone can suggest a better (i.e. more accurate and neutral) title, we can change it again.
But the current HN title is not a thesis at all. At best it's a characterization of the thesis of the piece. It's not a wrong characterization, but I don't see how it's useful. Certainly, he is indeed illustrating and referring back to Peter Naur's description of programming as theory-building, but this title doesn't tell me (a) what Peter Naur's view is, nor (b) why I should care, nor (c) whether this piece even agrees or disagrees with it.
The first subheading of "Your source code is worthless" is a running theme that connects everything. Yes, later on he calls to Naur's "Programming as Theory Building" article as an explanation for this observation, but the belief is more central than the explanation. It starts before the explanation and continues past the engagement with Naur.
I don't see how weakening this strong thesis by hiding it helps make things either more accurate or more neutral. Is it that it seems like an insult? Leave out "your", or change to "most" or "in general".
(In contrast, the article's title of "How to hire senior developers: Give them more autonomy" would be bad one. It is barely touched on, just thrown in at the end, as a conclusion on top of the meat of the piece.)
If I had to suggest something that covered what I consider the main points, and had more than the central theme: 'Source code alone is worthless as "Programming as Theory Building" suggests', but that's starting to attribute a stronger point of view to Naur than may be reasonable.
But the originally submitted title was perfectly okay.
Thanks for changing it instead of deleting it. How do you feel about "On the Value of Source Code"?
http://pages.cs.wisc.edu/~remzi/Naur.pdf
This is the power of web and http that opens the world to any curious mind. Your change of title made a book marketing page to a gate to new ideas to explore and discover.
Also out of curiosity I traced the HN list of the submissions of the original link, i.e., the author who is promoting his book:
https://news.ycombinator.com/submitted?id=cloogshicer
You can see that your change increased the attention to his marketing effort by a factor of 2!
Unfortunately this attention would hardly help him reach his audience, who are on the hiring side of the market and have completely different constraints than the engineering minded people dominated in HN.
Interesting conversation though.