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

41–50 of 96 posts

Re: What factors explain the nature of software?

#41

Post by a_c »

jprete wrote: post #32
a_c wrote: post #21

Earlier quoted context omitted.

It works in everyone’s favour. Founder got what his culture sets out to build. Customer got their features faster. Senior engineer clearly knows it is not the place for him and moved on. Everyone wins.

Probably feature development slowed to a crawl over a few years. Code debt isn't actually an abstract thing, it's just hard to explain to non-coders the thousand little slowdowns it injects into every project.

What I meant was the founder got what he asked for. Short term gain at the expense of sustainability. It is a feature rather than a bug. For a company looking for product market fit, "good code" might take a back seat. Andy Grove mentioned that an executive job is to, paraphrased, maintain the company culture. His context was about larger established companies. But I think the point still holds. It is the founder's job to sell his vision to his employees. It is the market's job to determine whether such vision thrives.

Re: What factors explain the nature of software?

#42

Post by randomdata »

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.

Perhaps, but there is nothing free market about financial services.

Re: What factors explain the nature of software?

#43

Post by AnimalMuppet »

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…

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 there. But there is, and if someone, somewhere, makes the opposite assumption, the gap matters.

Re: What factors explain the nature of software?

#44

Post by dllthomas »

jprete wrote: post #34
dllthomas wrote: post #22

Earlier quoted context omitted.

> I'm so sick of the fact that everyone is ok accepting "just barely passable" Isn't everyone ok with that by the definition of "passable"?

"Just barely passable" is the endless customer support carousel, the nickel-and-diming of airline fees, the addition of more and more ad space and cloned-content spam to web pages, and automobiles that spy on you to sell the data to marketers.

But if we updated our standards such that we no longer accept those things, they would no longer be passable, and something else would be "just barely passable".

My point - inasmuch as there was a serious one - wasn't that we shouldn't raise our standards but that the framing isn't particularly helpful in determining whether we should (while rhetorically sounding like it is).

Re: What factors explain the nature of software?

#45

Post by jimbokun »

> The act of seeing software in action changes what we think the software should be.

This is the ethos of Agile Development.

Get something in front of users as early and often as possible, because this will change their idea of what the software should be and better to find that out earlier than late in the process when the software is more difficult to change.

Re: What factors explain the nature of software?

#46

Post by jimbokun »

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…

This puts me in mind of a home owner on one of those renovations shows where the workers discover a structural flaw mid way through the job, and explain this means they don't have as much in the budget now for added features.

The equivalent of the boss in this story would demand to leave the structural issues unaddressed to keep the marble counter tops in the budget, and then the house would cave in a year later.

Re: What factors explain the nature of software?

#47

Post by Zigurd »

pixl97 wrote: post #36
Zigurd wrote: post #18

In project management I found it important in many cases to explain why "normal" project management - the kind where every task gets a description and resources assigned to it and you can do critical path analysis and resource leveling doesn't work for software. The reason is software tasks are often unique. The most important tasks are most often the unique ones. Therefore they are hard to estimate, and that makes y…

Another way I like saying it is "Non-unique software is generally called a library". In civil engineering there are a lot of small creeks to cross that you'll pretty much use a drag-n-drop bridge solution for. When you make an estimate of how long it will take to build, it's most likely going to be correct. It's when you come up to the wide river that you pull out the senior engineers and do a massive amount of homew…

That's the analogy I use in training. In civil engineering you have mostly predictable task durations that have mostly been done many times. You can even predict the variations for different soil conditions, etc. If you are making the same software repeatedly, something is wrong.

Agile, much because of Scrum jargon, has become annoying to a lot of people. Taking them back to the fundamentals - "oh that's why we don't do MS Project network diagrams" - helps.

Re: What factors explain the nature of software?

#48

Post by jimbokun »

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.

Yes. This is why you should immediately start interviewing when you observe this kind of behavior coming from management.

Re: What factors explain the nature of software?

#49

Post by d0mine »

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

Re: What factors explain the nature of software?

#50

Post by titzer »

AnimalMuppet wrote: post #43
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…

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 better than no spec. For example:

1. The loader should be able to parse an input file of up to 100MB in under 1 second.

2. The loader should support XYZ files version 3, 3.2, 3.3, and 4.0.

3. The loader should validate and reject erroneously formatted files.

4. The application should store internal state in robust storage that is independently inspectable.

5. The UI should be able to function if the backend database is down for less than 3 hours.

If you can't write ~1 page of such high-level requirements, why would you expect that you could start writing code? But we do. I mean, even I do!

Post reply on HN