[HN Gopher] Peter Naur's view of programming
___________________________________________________________________
Peter Naur's view of programming
Author : cloogshicer
Score : 162 points
Date : 2021-02-04 17:19 UTC (5 hours ago)
(HTM) web link (hiringengineersbook.com)
(TXT) w3m dump (hiringengineersbook.com)
| iamwil wrote:
| Anyone read the post author's book, Hiring Engineers? Is it any
| good and worth the $75?
| mynegation wrote:
| "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.
| cloogshicer wrote:
| Agreed, I think that argument back then was just bad.
| jjeaff wrote:
| What determines if a company is respected or not? Is Uber a
| respected company?
| deepsun wrote:
| Two more reasons Google doesn't touch others code:
|
| 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.
| pavel_lishin wrote:
| 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.
| mynegation wrote:
| True, but the premise of the article and my comment revolves
| around taking or seeing the code.
| StillBored wrote:
| Thinking about this more, I wonder if you can predict whether a
| software project is "failing" by the amount of code that is
| getting deleted early on.
|
| 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%
| [deleted]
| fwip wrote:
| The amount of code written isn't static, and doesn't map neatly
| to "amount of developer effort."
|
| 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.
| TheJoYo wrote:
| I'm missing where autonomy comes into this.
| mywittyname wrote:
| I feel like the Unix philosophy of very small programs that do
| one thing, and do it well, is an application of the concepts in
| this article.
|
| > 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.
| daotoad wrote:
| But to compose something large you begin to need hundreds of
| these small tools interacting.
|
| 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.
| npsimons wrote:
| That's not the post's headline; why did someone cherry pick this
| subheading? Is this simple clickbaiting?
| cloogshicer wrote:
| I think the title was changed by a moderator, but it's actually
| quite accurate now.
| vannevar wrote:
| "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.
| cloogshicer wrote:
| Agreed, worthless might have been a bit exaggerated.
| gabereiser wrote:
| _worthless-to-outsiders_ is more concise to me that conveys
| what the author was intending.
| paxys wrote:
| I have lost count of the number of startup founders I come across
| who have an unsuccessful product and are looking for an exit and
| go "we have all this amazing code. It has to be worth at least
| $X". No, all of your code is worth exactly $0 to any company
| looking to acquire you. They either want your product (read:
| users) as a whole or just the talent behind it. In 99% of such
| acquisitions your entire codebase will be thrown out.
| jayd16 wrote:
| "Kill your darlings" is probably a better aphorism.
|
| Obviously source code is useful on its face, and its also the
| truest documentation of current requirements. Worthless is an
| overstatement.
| blindm wrote:
| > Communicating the mapping of the code and the real world, as
| Naur describes, would have required us to document all these
| processes in meticulous detail. If we had tried to, I believe the
| result would've been multiple hundred pages describing the
| business processes
|
| 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.
| Simplicitas wrote:
| Hyperboles will always derail any conversation
| gfody wrote:
| 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.
| IggleSniggle wrote:
| 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.
| gfody wrote:
| if source code takes the form of human language I would no
| longer call it source code - it still might be excrement but
| not necessarily so.
| zwieback wrote:
| 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.
| yudlejoza wrote:
| - There's no such thing as programming
|
| - There's only research programming
| hallarempt wrote:
| _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.
| cloogshicer wrote:
| 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
| :)
| bennysonething wrote:
| Thanks for writing the article, see my comment else where in
| this thread. It's really helped me. I just been througha
| rough ride of a handover.
| hombre_fatal wrote:
| 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.
| ghaff wrote:
| I think both can be true.
|
| 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.
| gpm wrote:
| 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.
| cloogshicer wrote:
| > Most apps aren't in such a difficult space and keep
| working basically forever.
|
| Sadly, this doesn't match my experience. Software that
| isn't actively maintained always dies, sooner or later.
| btilly wrote:
| Whether this is true depends on what you do.
|
| 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.
| Jtsummers wrote:
| 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.
| navanchauhan wrote:
| AutoDock Vina[0] is one of the most popular molecular-
| docking softwares used (if we go by papers citing it). It
| was last updated on May 11, 2011.
|
| 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
| tomc1985 wrote:
| 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.
|
| Code is eternal.
| asciident wrote:
| 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?
| tomc1985 wrote:
| Hah, no I paid for Sublime Text way back when, and before
| that I was big on Notepad++. I rarely update either
| though :)
| 1996 wrote:
| > 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.
| rytill wrote:
| > 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.
| navanchauhan wrote:
| Context: They are the maintainer of Krita[0], a really popular
| open-source painting program.
|
| [0] https://krita.org
| oaiey wrote:
| 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.
| cloogshicer wrote:
| 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.
| Quarrelsome wrote:
| 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.
| throwawaygh wrote:
| _> Especially for the lower-level components, a good amount of
| research had been involved. We worked closely with an academic
| institute that specialized in computer vision. In short, this
| project wasn't something that anybody could just easily recreate.
| So one of the assumptions we had implicitly made was that our
| source code was one of the company's major assets._
|
| Why not patent?
| [deleted]
| FrozenVoid wrote:
| 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).
| jimmyvalmer wrote:
| 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.
| seanmcdirmid wrote:
| 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.
| Pete-Codes wrote:
| Re your newsletter form, I'd take out the first name requirement.
| cloogshicer wrote:
| Thanks for your suggestion! It's actually optional. I had a
| problem with spam signups and thought it might help a bit.
| QuercusMax wrote:
| 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.
| rorykoehler wrote:
| 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.
| closeparen wrote:
| It's not a one-way transfer of information.
|
| - 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.
| QuercusMax wrote:
| 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.
| cloogshicer wrote:
| I think the point that Naur was trying to make is exactly
| that this process (unfortunately) doesn't scale.
|
| That is my experience at least (even in very well documented
| projects).
| chubot wrote:
| 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.
| rorykoehler wrote:
| I've never been unhappy when provided with thorough
| documentation.
| majormajor wrote:
| 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...
| ilaksh wrote:
| 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.
| solatic wrote:
| 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.
|
| You are who you hire.
| dbrueck wrote:
| The article is great, though a more accurate (but admittedly less
| thrilling) title would have been "Poorly Documented Source Code
| Is Virtually Worthless".
|
| 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.
| jimmyvalmer wrote:
| > "Poorly Documented Source Code Is Virtually Worthless".
|
| 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.
| jariel wrote:
| 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.
| kissgyorgy wrote:
| 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!
| lumost wrote:
| This works to some extent, however it's pretty rare that
| engineers go more than 1 commit deep into the git blame.
| kissgyorgy wrote:
| No it's not at all. I do it daily. You have to learn the
| tools you use every day!
| cloogshicer wrote:
| While I agree that good commit messages help, I think a lot of
| this info can't be reasonably conveyed through them.
|
| 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.
| Ericson2314 wrote:
| "source code being worthless" is actually a huge red flag that
| something is deeply wrong with the way our industry works. There
| is too much in-house knowledge that isn't being codified.
| Software production shouldn't be like e.g. Jet engine production,
| where it's all nontransferable lore.
|
| 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.
| paxys wrote:
| You could do all that and the code would still not have any
| intrinsic worth, because if a company gets their hands on it
| they don't automatically get a team of developers with domain
| expertise to maintain it going forward. That's where the real
| value is. Knowledge and experience can never be codified.
| StillBored wrote:
| So your saying it would take someone the same amount of time
| to say recreate an OS like windows, without the source code
| as it would to become proficient in building and maintaining
| it?
|
| 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.
| ErikAugust wrote:
| I think it's incentives, partially.
|
| 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).
| Ericson2314 wrote:
| > 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".
|
| 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.
| StillBored wrote:
| I think the author is seriously confused over the value of some
| crap his startup created in a couple man years vs actual products
| with market share, long term maintenance and thousands+ of man
| years of engineering/testing/documentation time. He even admits
| that they were rewriting large parts of it on a regular basis.
| That by itself indicates much of the code actually had little
| value, if the engineers themselves were throwing it away.
|
| It would be really hard to convince MS/Google/apple/etc that
| their primary products source code doesn't have any value.
| horsawlarway wrote:
| I disagree with you... sort of.
|
| 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)
| StillBored wrote:
| Well I don't disagree with that either. Only that I must
| point out that libre washing a company with an open source
| product here/there doesn't really count. Sure android is
| open, but google isn't using it to make money directly,
| instead it feeds into the closed source ad/marketplace
| offerings.
|
| 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.
| ajsharp wrote:
| "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."
|
| [shudder]
| DavidAdams wrote:
| Yeah, my first thought after reading that anecdote was that the
| new COO should have been fired.
| gamacodre wrote:
| And the CTO too, for caving to that argument.
| aeldidi wrote:
| Rather than "Source Code is Worthless", I find it makes more
| sense to think of the lesson learned here as "Source Code is Only
| Worth Something to the Public if it's Well Documented and
| Stable", which happens to be true more often in practice.
|
| 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.
| pan69 wrote:
| Source code isn't worthless, it's just not as important as the
| developers who wrote it because those developers can write a
| next, much better version, of the same software with the domain
| knowledge they have acquired writing the previous version(s). In
| practice this means that source code is disposable.
| bjornsing wrote:
| 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... ;)
| dbsmith83 wrote:
| I agree with the conclusions drawn in the article, but not the
| premise. Source code is definitely not worthless. Two examples:
|
| 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
| enobrev wrote:
| It seems that you not only agree, but argue further that source
| code is a liability.
| dbsmith83 wrote:
| Hah, nice try, but no. Arguing that something is a liability
| if it fell into the wrong hands does not mean it is worthless
| or worth less than zero. It simply means it is worth
| protecting.
| daotoad wrote:
| This fits nicely with some ideas I've been working on about
| "Tribal Knowledge". It's going to take some thought to integrate
| fully. I am primarily looking at the work of Ong on orality and
| the distinctions he draws between oral and literal cultures.
|
| 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.
| pasquinelli wrote:
| would the oral transmission of information be what's called in
| other industries training?
| asiachick wrote:
| 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.
| cloogshicer wrote:
| 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.
| ajsharp wrote:
| 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.
| TheJoYo wrote:
| > They would be much faster just building it themselves from
| scratch, than trying to understand the crummy code we had hacked
| together.
|
| 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.
| Vinnl wrote:
| The relative worthlessness of source code can easily be seen when
| the situation is flipped around. When you're told you can look at
| e.g. a competitor's source code, some open source code somewhere,
| or a prototype that a colleague already built during a proof-of-
| concept, that will almost never make you go much faster.
|
| 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.
| shahrk wrote:
| Unless you are Waymo and the theft is by one of your employees.
| [deleted]
| cccc4all wrote:
| Source code is worthless AFTER it's written.
|
| It still has to be written first.
| superjan wrote:
| This is easier to reason about if it's not about your own code.
| Consider this: would you swap your own codebase for your
| competitor's if you had the chance? For me, it's a resounding no.
| I bet it's the same from their perspective.
| cloogshicer wrote:
| The referenced article by Peter Naur (Turing Award winner,
| invented Backus-Naur-Form) is well worth a read.
| ivan_ah wrote:
| Here is a link to a PDF version of this paper:
|
| [Programming as Theory Building -- Naur 1985]
| https://demo.cygale.net/naur1985programming.pdf
| groby_b wrote:
| 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.
| [deleted]
| dang wrote:
| That's an egregiously baity title. That's not cool here:
| https://news.ycombinator.com/newsguidelines.html
|
| Edit: The submitted title was "Your source code is worthless".
| I've changed it now.
| wnoise wrote:
| And yet the current title ("Peter Naur's view of programming")
| now contains even less information about the content of the
| article. It may be less "clickbaity" -- I certainly am less
| inclined to click on it, but it's also less useful.
| dang wrote:
| I would say it contains much more information, in addition to
| being accurate.
|
| If anyone can suggest a better (i.e. more accurate and
| neutral) title, we can change it again.
| jimmyvalmer wrote:
| It's baity because it's true.
| dang wrote:
| That is not an adequate theory of baitiness.
| breck wrote:
| The more you design your program for the current world, the
| faster it will go out of date. Try to identify what will still be
| useful in 30 years, and get that part right.
| dwohnitmok wrote:
| 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.
| dehrmann wrote:
| > 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.
| jhallenworld wrote:
| Source code is most valuable to the person who wrote it / knows
| it intimately. If I can use my code on different jobs it will
| definitely save me time. For this reason I try to make any
| library code MIT licensed. This allows me to use it for different
| clients without them complaining. Our contracts are set up to
| allow this.
|
| Often the customer's proprietary code is a small fraction of all
| the code.
| bennysonething wrote:
| This is probably one the most poignant things I've read about
| programming. I've recently been through a handover, left on my
| own at at a new job, with a long back log full of fairly useless
| stories, left to forge relationships with the business. Mostly
| left depressed and stressed. All the while a manager said "I
| don't understand why the handover is taking so long, it's all
| documented". Yeah the documentation didn't really tell me much as
| I lacked the business context. I'm brand new to this domain too.
| The article has put into words what I've been feeling for the
| last year.
| jimmyvalmer wrote:
| 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).
| castwide wrote:
| The article makes a lot of good points, but I disagree with the
| notion that source code is worthless. The true test of the
| source's value isn't what would happen if it got stolen. It's
| what would happen if it disappeared altogether.
| IggleSniggle wrote:
| I am sometimes guilty of reading the comments before reading the
| article. I often find the reactions more concise, insightful, and
| valuable to me than the source material.
|
| 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.
| CryptoGhost wrote:
| The author doesn't make a good case for "The main value of a
| software company is the mapping of source code and problem
| space in the developer's heads" being a universal truth. There
| are some problem domains and practical development and
| deployment roadblocks that simply make certain source code more
| valuable than others. Nowadays it seems people are more willing
| to throw money at open sourcing solutions so competing firms
| don't have to roll their own but thats not a hard and fast
| phenomenon.
| nitwit005 wrote:
| The problem with saying it's about developers building up theory
| is that we all tend to forget quite a bit. Code tends to contain
| a ton of fixes, versioning details, or algorithmic tricks no one
| remembers.
|
| I've certainly rebuilt something from scratch only to immediately
| stub my toe.
___________________________________________________________________
(page generated 2021-02-04 23:00 UTC)