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

21–30 of 96 posts

Re: What factors explain the nature of software?

#21

Post by a_c »

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…

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.

Re: What factors explain the nature of software?

#22

Post by dllthomas »

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'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"?

Re: What factors explain the nature of software?

#23

Post by wavemode »

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…

Software specification is circular because what we write down as a requirement is going to depend heavily on what is feasible to implement. But feasibility of implementation is often not clear until you actually try to implement the thing.

In fact, I would go so far as to say that, if in the design phase the precise structure of every single piece of what you are implementing, and the scope and feasibility of all alternatives, is known and crystal clear, then the project is trivial and probably does not need a design phase - you might as well just write the code.

The article makes this point as well: "a complete, abstract specification is, in general, at least as much work as creating the software itself"

Re: What factors explain the nature of software?

#25

Post by Jaygles »

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…

There's only so much requirements can do to prepare one for a project. At some point there's diminishing returns on time spent spec'ing something out. And of course requirements can change, so some amount of flexibility in being able to pivot while work is in progress is ideal.

Building software is usually more of a process than a plan. This is in contrast of traditional engineering where you absolutely need a rigid plan to build something like a bridge or a building. Of course reality is messy and no plan will be perfect

Re: What factors explain the nature of software?

#26

Post by FrustratedMonky »

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.

Re: What factors explain the nature of software?

#27

Post by datadrivenangel »

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…

Would it be ethical in a situation like this to hide all the technical improvements and just show the increased speed of client facing delivery?

Seems like everyone would be happier.

Re: What factors explain the nature of software?

#28

Post by whilenot-dev »

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…

6 years ago I gave a C-level guy a fresh copy of Perform or Else[0] on my way out. I don't know if he even read it.

[0]: https://www.routledge.com/Perform-or-Else-From-Discipline-to...

Re: What factors explain the nature of software?

#29

Post by rqtwteye »

evilduck wrote: post #10
gavinhoward wrote: post #5

Earlier quoted context omitted.

I think you are both right. But I don't think GP was ignoring clients. If anything, he was doing what those clients wanted by moving to containers and a cloud architecture. And I say that as someone that doesn't like those things.

I've never seen outsourcing of a company's core product result in anything but litigation. If a team legitimately made a 2000% leap in throughput and it wasn't just from manipulating metrics, and then that still wasn't good enough then nothing will be satisfactory in the eyes of that owner, you rightfully should give up that battle and find greener pastures. Expecting someone to come in and wave a magic wand of 4000%…

There are a lot of managers who believe you should always put a squeeze on devs and keep the org in constant panic mode. Nothing will ever be good enough. If you achieve one goal, you get hit with another crazy deadline. It never ends.

Re: What factors explain the nature of software?

#30

Post by rqtwteye »

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 have learned over the years that there are different types of devs. Some are ok with cranking out features without regard for overall architecture and can handle the chaos of constant quick fixes over previous quick fixes. There are others (like me) who like well designed systems and get stressed when they are asked to just crank out features without regard for the overall system.

Personally I believe that my approach achieves higher velocity over time because the guys who just do quick bandaid fixes get bogged down over time with technical debt. But not everybody agrees.

I definitely think you need to know where you are on that spectrum and find an org that fits your style. Otherwise you are in for constant pain and unhappiness.

Post reply on HN