Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What factors explain the nature of software?

tratt.net

Post reply on HN
Print view View original

51–60 of 96 posts

Re: What factors explain the nature of software?

#51

Post by AnimalMuppet »

titzer wrote: post #50
AnimalMuppet wrote: post #43

Earlier quoted context omitted.

To expand on what others have said: If the spec isn't the size of the software, then it leaves out details. But "everybody knows what we mean" - until they try to implement it. Then they find out part of what wasn't specified. "Part of", because there's the other part, which wasn't specified, and they just assumed there was only one possible answer, and so they didn't even realize that there was a gap in the spec the…

Well no, the whole point is that the spec is not detailed enough to be code. Of course it leaves out details. I feel like this conversation will diverge to generalities without an example. So, take the WebAssembly spec for example. There's a reason it's written in "spec" language and not just some C code (or any other programming language, for that matter). But that's a very precise spec. In reality, a loose spec is…

I absolutely agree that you need requirements. If you don't know what you're trying to build, it makes it really hard to build it. (And, one page? That's hopelessly inadequate for anything real. But I agree, too often we just start writing...)

But I think where the disagreement comes is in the difference between requirements and specification. The example you gave is, in my view, not a spec at all, just requirements.

Take item 4: That could mean anything. It could mean a SQL database with a published schema, or it could mean a 1 GB file on disk that I can view in a hex editor. (The file probably can't be in /tmp though, because you said "robust".)

So people try to make the requirements more specific, so that they "specify" exactly what the software does. And that's where my previous comment comes in - you can't make it specific enough to answer all the questions. Which was one of the points of the article.

Re: What factors explain the nature of software?

#52

Post by mcguire »

FrustratedMonky wrote: post #26
browningstreet wrote: post #2

I was once the CTO of a financial services firm that had been founded by a non-technical person. When I was hired the code base was in poor shape. With a bit of guidance we overhauled the codebase in 3 months and swept clean about 15 years of technical debt. They were using a 13 year old version of the compiler. New clients were requiring audits and attestations we wouldn’t have been able to pass. I was able to hire…

Shouldn't the free market drive companies with these type of leaders down ? They should become swamped by the faster more agile competitors? But sadly, it seems the inertia keeps some pretty ignorant organizations functioning for decades.

Eventually, yes. Unless they sell to another company and the technical debt goes into the trash with the company's product.

On the other hand, "the market can remain irrational longer than you can remain solvent."

Re: What factors explain the nature of software?

#53

Post by eurekin »

browningstreet wrote: post #2

I was once the CTO of a financial services firm that had been founded by a non-technical person. When I was hired the code base was in poor shape. With a bit of guidance we overhauled the codebase in 3 months and swept clean about 15 years of technical debt. They were using a 13 year old version of the compiler. New clients were requiring audits and attestations we wouldn’t have been able to pass. I was able to hire…

That reminds me of one case, where an author of software saw any improvement or genuine feedback as a personal attack - directed at him and his "legacy". Can't go into specifics, but only features directly or indirectly praising the original software were allowed. I was student/intern at the time and learned about that the hard way.

Still, one of most important teaching moment to this day.

Re: What factors explain the nature of software?

#54

Post by mcguire »

titzer wrote: post #20

> The circular specification problem > The only way to know exactly what software we want to build is to fully specify it: without doing so, there will be gaps between our vague ideas and harsh reality. However, a complete, abstract specification is, in general, at least as much work as creating the software itself — in many cases, it is substantially more work. Well, there is a way to do this: it's called requiremen…

"...a new (often anticipatable) requirement seems to appear..."

And often not, particularly when you are building a new system. And if you are replacing an existing system, the requirements that you discover are usually, "it must work exactly the same way as the old system."

Re: What factors explain the nature of software?

#55

Post by fabianholzer »

systems wrote: post #3
browningstreet wrote: post #2

I was once the CTO of a financial services firm that had been founded by a non-technical person. When I was hired the code base was in poor shape. With a bit of guidance we overhauled the codebase in 3 months and swept clean about 15 years of technical debt. They were using a 13 year old version of the compiler. New clients were requiring audits and attestations we wouldn’t have been able to pass. I was able to hire…

"put the donkey, where the owner of the donkey wants you to put the donkey" - egyptian proverb i dont know how much money this company was making, and why it couldnt invest in both backend and client facing communications but, on the other hand, being client focused and continuously delivering client facing feature, might be the thing that keeps the revenu streams coming in other words, i used to always take the dev…

> its a financial service, not a software company

I have no experience in the financial industry, but I work in a field which is also highly regulated (medical devices). Failure to pass audits or be otherwise compliant to regulation can very much make the difference between having or not having any business at all.

Paying of decades worth of debt in a few month where clients see no shiny new features was likely more and better service than that founder-CEO type deserved.

Re: What factors explain the nature of software?

#56

Post by skydhash »

TheAceOfHearts wrote: post #15
bluefirebrand wrote: post #11

Earlier quoted context omitted.

> but, on the other hand, being client focused and continuously delivering client facing feature, might be the thing that keeps the revenu streams coming I firmly reject this. If you can't build quality then you don't deserve to be in business I'm so sick of the fact that everyone is ok accepting "just barely passable" It has lead to everything new being built is crap. New housing is crap, new furniture is crap, new…

I do get frustrated with the state of modern software, but often times the comparison ends up being between a crappy version of something or nothing at all. One of the major problems is that many of our core software assumptions were based on design decisions made decades ago, when the industry was young and figuring out a million details. I've mostly done web dev, but recently was trying out IMGUI and was amazed by…

> The platform owners could so a lot to ease this burden, but everyone wants their own little fiefdom.

The thing is that most people use one platform. So the owners try to present one consistent view on how to use that platform. Trying to provide a common paradigm across platform is the goal of companies that love their brands too much. But as a user, I just want for everything to function similarly so I don't have to read a manual for each app. I've done Android dev and dabbled in iOS, but now I'd only recommend React Native if what you want can be a web app, but you want the extra UI performance and some native features. If you want something more complex or consistent, go native.

Re: What factors explain the nature of software?

#57

Post by avmich »

browningstreet wrote: post #2

I was once the CTO of a financial services firm that had been founded by a non-technical person. When I was hired the code base was in poor shape. With a bit of guidance we overhauled the codebase in 3 months and swept clean about 15 years of technical debt. They were using a 13 year old version of the compiler. New clients were requiring audits and attestations we wouldn’t have been able to pass. I was able to hire…

> Senior engineer gave him a copy of The Cathedral and the Bazaar, just to share something that could lead to some kind of common vocabulary. Founder spent weekend marking up his copy and on Monday

I'd quite like to read those markings. Do you have them?

Re: What factors explain the nature of software?

#58

Post by jandrewrogers »

d0mine wrote: post #49
jandrewrogers wrote: post #40

These are to some extent manifestations of another factor. In software engineering, we skip entirely an essential step in the engineering process which is central to mature engineering domains involving complex dynamic systems e.g. chemical engineering. If we skipped that step in those other engineering domains, we would see design disasters and gross inefficiencies analogous to what we see in complex software today.…

There are tools such as TLA+ that help with modeling at the level higher than executable code. Recent talk for example: Fifteen years of formal methods at AWS Marc Brooker, Amazon AWS https://youtu.be/HxP4wi4DhA0

These don't model key properties of software for systems engineering purposes. Software can be technically correct in a formal sense and also broken in all real implementations if it doesn't satisfy reasonable engineering constraints, like efficiency, scalability, concurrency, latency variance, or strange resonances in the system (a significant performance issue in HPC).

It is an optimization problem, not a correctness problem.

If you applied the same systems solving methods to software as physical engineering, you should be able to predict system performance, concurrency, scaling, etc characteristics on a given hardware environment in concrete absolute terms without writing a line of code. The whole "build then measure" thing would be unnecessary. This is normal in physical engineering.

I know software performance engineers that can predict these kinds of characteristics with surprising accuracy on a localized basis because they carry detailed system models in their heads, but that is a rare skill and to scale that up to a larger, more complex software system you really need some kind of automated solver. We use automated solvers in other engineering domains for the same reason -- human brains struggle to do this bit well.

Re: What factors explain the nature of software?

#59

Post by HeyLaughingBoy »

spit2wind wrote: post #9
browningstreet wrote: post #2

I was once the CTO of a financial services firm that had been founded by a non-technical person. When I was hired the code base was in poor shape. With a bit of guidance we overhauled the codebase in 3 months and swept clean about 15 years of technical debt. They were using a 13 year old version of the compiler. New clients were requiring audits and attestations we wouldn’t have been able to pass. I was able to hire…

CatB is a fine book. That feels like such add choice for the situation, aside from just seeing if the person was willing to engage with ideas within software. I'm curious what texts people would suggest for a non-developer to get some insight. The ones that come to my mind are the Mythical Man Month, Peopleware, Facts and Fallacies of Software Engineering by Glass, or maybe even the 1968 NATO report on software engin…

Whatever it is, it should be as short as possible.

Re: What factors explain the nature of software?

#60

Post by HeyLaughingBoy »

fabianholzer wrote: post #55
systems wrote: post #3

Earlier quoted context omitted.

"put the donkey, where the owner of the donkey wants you to put the donkey" - egyptian proverb i dont know how much money this company was making, and why it couldnt invest in both backend and client facing communications but, on the other hand, being client focused and continuously delivering client facing feature, might be the thing that keeps the revenu streams coming in other words, i used to always take the dev…

> its a financial service, not a software company I have no experience in the financial industry, but I work in a field which is also highly regulated (medical devices). Failure to pass audits or be otherwise compliant to regulation can very much make the difference between having or not having any business at all. Paying of decades worth of debt in a few month where clients see no shiny new features was likely more…

I'm also in medical devices and I had the same reaction. "If you're out of Compliance, you're out of business."
Post reply on HN