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

The economics of software teams: Why most engineering orgs are flying blind

viktorcessan.com

Post reply on HN
Print view View original

201–210 of 299 posts

Re: The economics of software teams: Why most engineering orgs are flying blind

#201

Post by Aurornis »

rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.

I’m growing tired of this aphorism because I’ve been in enough situations where it was not true.

Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole reason the business opportunity existed was that it was an extremely hard engineering problem.

I can see how one could go through a career where the programming itself is not that hard if you’re mostly connecting existing frameworks together and setting up all of the tests and CI infrastructure around it. I have also had jobs where none of the programming problems were all that complicated but we spent hundreds of hours dealing with all of the meetings, documents and debates surrounding every change. Those were not my favorite companies

Re: The economics of software teams: Why most engineering orgs are flying blind

#202

Post by antonvs »

rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> Figuring out what exactly needs programmed is the hard part.

Making good decisions is the hard part, whether it's about programming or about what needs to be programmed.

Re: The economics of software teams: Why most engineering orgs are flying blind

#203

Post by Aurornis »

siliconc0w wrote: post #185
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

+1 A huge amount of software - probably most - is not actually generating value and in many cases is actually reducing value. I've seen teams build and re-build the same infrastructure over and over. I saw a request that could have been met with a few SQL queries and a dashboard got turned into a huge endeavor that implements parts of an ETL, Configuration Management, CI/CD, and Ticketing system and is now in the cri…

One of the most confusing moments in my early career was when someone spent two whole quarters building a custom tool that did something a mature and well respected open source project did for us. There was no advantage to his tool and he would admit it when cornered by the question.

We all thought he would get reprimanded for wasting so much time, but by the time management figured out was happening they decided they needed to sell it as a very important idea rather than admit they just spent $100,000 of engineering time on something nobody needed. So it turned into something to celebrate and we were supposed to find ways to use it.

That company went down in flames about a year later. That’s how I learned one way to spot broken organizations and get out early rather than going down with the ship.

Re: The economics of software teams: Why most engineering orgs are flying blind

#204

Post by marcosdumay »

febusravenga wrote: post #65
csomar wrote: post #33

Earlier quoted context omitted.

He is selling consulting around AI/LLM.

In other words, he's cutting branch he's sitting on.

That would only be a problem if his saw could actually cut wood.

Re: The economics of software teams: Why most engineering orgs are flying blind

#205

Post by 9rx »

CodeMage wrote: post #184
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> the actual programming is not the hard part We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard .

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

Determining what to program can be hard, but that was already considered earlier.

The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programming is hard, but rather art that is trying to push boundaries is hard. That is something that holds regardless of the artistic medium.

Re: The economics of software teams: Why most engineering orgs are flying blind

#206

Post by ravenstine »

Aurornis wrote: post #201
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism because I’ve been in enough situations where it was not true. Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole…

Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

The saying also ignores the fact that humans are not perfect programmers, and they all vary in skills and motives. Being a programmer often not about simply writing new code but modifying existing code, and that can be incredibly challenging when that code is hairbrained or overly clever and the people who wrote it are long gone. That involves programming and it's really hard.

Re: The economics of software teams: Why most engineering orgs are flying blind

#207

Post by mikebenfield »

9rx wrote: post #205
CodeMage wrote: post #184

Earlier quoted context omitted.

> the actual programming is not the hard part We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard .

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? Determining what to program can be hard, but that was already considered earlier. The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programm…

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

They do? I've known plenty of kids and young adults who utterly failed to become even borderline competent at programming.

Re: The economics of software teams: Why most engineering orgs are flying blind

#208

Post by juancn »

The over-simplification rubs me the wrong way, for example:

    Consider a team of eight engineers whose mission is to build and maintain an internal developer platform serving one hundred other engineers. This is a common     organizational structure, and it is one where the financial logic is rarely examined carefully.
    
    The team costs €87,000 per month. To justify that cost, the platform they build needs to generate at least €87,000 per month in value for the engineers who use it.     The most direct way to measure that value is through time saved, since the platform’s purpose is to make other engineers more productive.
    
    At a cost of €130,000 per year, one engineer costs approximately €10,800 per month, or around €65 per working hour. For the platform team to break even, their     platform needs to save the hundred engineers they serve a combined total of 1,340 hours per month. That is 13.4 hours per engineer per month, or roughly three hours     per week per person.
There's a fungibility assumption which is pervasive here. In most cases, a platform team is there not "to save time".

It's there to deal with cross concerns that would be not only time consuming but could be business threatening, and in some cases, you keep there more expensive engineers that ensure that certain critical things are done right.

Too much snake oil for my taste.

Re: The economics of software teams: Why most engineering orgs are flying blind

#209

Post by 9rx »

mikebenfield wrote: post #207
9rx wrote: post #205

Earlier quoted context omitted.

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? Determining what to program can be hard, but that was already considered earlier. The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programm…

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? They do? I've known plenty of kids and young adults who utterly failed to become even borderline competent at programming.

They don't? It is taught in schools in the early elementary level. I see no indication that most are failing.

I think we can agree that few of them would be economically useful due to not knowing what to program. There is no sign of competency on that front. Certainly, even the best programmer in the world could theoretically be economically useless. Programmers only become economically useful when they can bridge "what to program".

Re: The economics of software teams: Why most engineering orgs are flying blind

#210

Post by pron »

jimbokun wrote: post #182
chermi wrote: post #153

Earlier quoted context omitted.

This just sounds like incomplete specs to me. And poor testing.

We call the complete specs "source code".

... and it still doesn't work. In the Anthropic experiement, the model was trained on a reference implementation and the agents still failed.
Post reply on HN