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

11–20 of 96 posts

Re: What factors explain the nature of software?

#11

Post by bluefirebrand »

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…

> 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 software is crap

I get that building nice things is expensive and takes time, but I want to live in a world of nice things instead of this constant race to the bottom, produce endless quantities of crap world that we are in right now

Doesn't anyone else feel like we're being crushed under all this crap we're building?

Re: What factors explain the nature of software?

#12

Post by bluefirebrand »

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…

Every now and then I have to ask my PM at work "If I give you a second copy of the Mythical Man Month, could you read it twice as fast"?

He doesn't like that question, but it does get the point across

Re: What factors explain the nature of software?

#13

Post by [deleted] »

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

How did you measure velocity?

[deleted]

Re: What factors explain the nature of software?

#15

Post by TheAceOfHearts »

bluefirebrand wrote: post #11
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…

> 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 tiny memory footprint and with how quickly it started. But even that system has limitations, requiring that you learn a bunch of details for targeting different platforms. Isn't it amazing that native cross platform development is still so difficult in 2024? The platform owners could so a lot to ease this burden, but everyone wants their own little fiefdom.

Re: What factors explain the nature of software?

#16

Post by cowanon44 »

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…

I find Microsoft's 5 Pillars in their Well-Formed Architecture to be a useful way to explain this to non-technical people.

At the start of a project, fully focusing on your features makes sense. But as a project grows, non-functional concerns can sabotage the business model if not addressed.

- Reliability

- Security

- Cost optimization

- Performance Efficiency

- Operational Excellence

The first four have a direct impact on the customer. Buggy or insecure software, or excess costs, will all affect the customer directly.

The fifth point is about devops, and making sure that we can continuously (as a process) meet the customer's needs in all of these areas.

I've found that if I can fit refactoring into one of these pillars, it is much easier to explain to non-technical people. Of course, some people just can't be helped, and aren't open to alternate ways to think about software projects.

Re: What factors explain the nature of software?

#17

Post by cess11 »

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…

I think that was a good move by the senior engineer. In part because I've done something similar and want to believe it's the right thing to do.

Did it change anything? Did the founder manage to keep things going?

Re: What factors explain the nature of software?

#18

Post by Zigurd »

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 your carefully crafted schedule useless very quickly after a project starts.

Agile, mostly in the form of Scrum is supposed to be the answer, but in many cases Scrum people keep banging their heads against the task estimation brick wall just like their Gantt/CPM chart predecessors.

That's why task uniqueness and the inevitable, intractable, why-even-try unreliability of estimates is an important part of the nature of software.

Re: What factors explain the nature of software?

#19

Post by Zigurd »

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

How did you measure velocity?

Story points are unitless. Therefore story point velocity is measured in the inverse of time.

Re: What factors explain the nature of software?

#20

Post by titzer »

> 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 requirements. There's a whole subfield of Software Engineering called Requirements Engineering that deals with exactly this. The fact that we don't stop to write down even a one page description with bullet points of what software should do is damning as a field.

We'd instead rather just jump right in and then later spend hours, days, weeks, months, even years later refactoring the wrong thing we started with, or banging on it with a hammer every time a new (often anticipatable) requirement seems to appear.

Sure, software development is a young field, but it will never mature if we constantly ignore and even forget the basics.

Post reply on HN