Live data from Hacker News

Peter Naur's view of programming

hiringengineersbook.com

51–60 of 198 posts

Re: Peter Naur's view of programming

#53
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.

Re: Peter Naur's view of programming

#54
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.

Re: Peter Naur's view of programming

#55
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.

Re: Peter Naur's view of programming

#56
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.

Re: Peter Naur's view of programming

#58
post #43

Earlier quoted context omitted.

> 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.

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 prog…

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.

Re: Peter Naur's view of programming

#60

"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…

Agreed, worthless might have been a bit exaggerated.

worthless-to-outsiders is more concise to me that conveys what the author was intending.
Post reply on HN