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.
Peter Naur's view of programming
21–30 of 198 posts
Re: Peter Naur's view of programming
#22“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.
What determines if a company is respected or not? Is Uber a respected company?
Re: Peter Naur's view of programming
#23“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.
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.
Re: Peter Naur's view of programming
#24When 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.
Re: Peter Naur's view of programming
#25Source 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).
Re: Peter Naur's view of programming
#26You 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.
Re: Peter Naur's view of programming
#27It is very often a developer perspective that the source code and the software product is the core delivery. Interestingly that is often not true. Customer care, project management, sales, marketing and so many roles contribute so much more to the value creation than often visible to a developer.
I completely agree, that's why I wrote in a footnote:
> However, I believe this statement is only true for software companies where the core technology is the main asset. For many software companies, the main value might not lie in their technology, but in other things, such as the network effects, relationships to customers, etc.
Re: Peter Naur's view of programming
#28“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.
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.
Re: Peter Naur's view of programming
#29The 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.
Re: Peter Naur's view of programming
#30Working 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.