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

211–220 of 299 posts

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

#211

Post by CodeMage »

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?

That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bugs that are hard to reproduce.

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

#212

Post by 9rx »

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

No, that's exactly the topic of the article. The claim is that most software teams do not consider the financial impact of their work. Is what they are doing producing value that can be measured in dollars and cents and is greater than the cost of their combined cost of employment? The article suggests that there is a lot of programming being done without considering what exactly needs to be programmed.

> The article suggests that there is a lot of programming being done without considering what exactly needs to be programmed.

And the parent rightfully points out that you cannot know exactly what needs to be programmed until after you've done it and have measured the outcome. We literally call the process development; for good reason. Software is built on hunches and necessarily so. There is an assumption that in the future the cost of the work will pay back in spades, but until you arrive in that future, who knows? Hence why businesses focus on metrics that try to observe progress towards finding out rather than tracking immediate economic payoff.

The interesting takeaway from the article, if you haven't give this topic much thought already, is that the changing financial landscape means that businesses are going to be more hesitant to take those risks. Right now there still seems to be enough optimism in AI payoffs to keep things relatively alive, but if that runs out of steam...

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

#213

Post by 9rx »

CodeMage wrote: post #211
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? That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school". Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bu…

> That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

> there are many different ways to write a program to satisfy them.

"What to program" being hard was accepted from the onset and so far we see no disagreement with that.

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

#214

Post by Yokohiii »

ravenstine wrote: post #206
Aurornis wrote: post #201

Earlier quoted context omitted.

> 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…

Isn't overly clever code a result of programmers doing simple things the hard mode?

Okay it's a spicy take, because juniors also tend to write too smart code.

Figuring out what to do and how to do it, is maybe not hard but it's effort. It's a hidden thing because it's not flat coding time, it requires planning, research, exploration and cooperation.

It's also true that some seemingly simple things are very hard. There are probably countless workarounds out there and the programmer wasn't even aware he is dodging an NP hard bullet.

Both arguments are valid.

I think the weight leans on effort, because effort is harder to avoid. Work, complexity, cruft piles up, no matter what you do. But you can work around hard problems. Not always but often enough. Not every business is NASA and has to do everything right, a 90% solution still generates 90% returns, and no one dies.

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

#215

Post by cm11 »

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…

This concept exists outside of engineering too. It's captured in the more negatively intentioned: ““The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer". In user research, it's a much better signal when people correct you than when they agree. Politeness is easy—especially under the circumstances (power dynamic of you paying them, they only half care about your work, people generally want to be nice/agreeable, etc.)—such that you should be weary of it. Similarly trying to get real project goals or real requirements or real intentions from a PM or a boss, who may well be hiding that they there isn't much vision underneath things, is the same. The problem is that as productive as it is for developing the team's thinking, it will (1) probably come off as unproductive and challenging because you're slowing "progress" and (2) saying dumb wrong things makes you seem dumb and wrong. But per the concept, even when you do have the foresight to question, you're not allowed to just ask.

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

#216

Post by kevin_nisbet »

RamblingCTO wrote: post #196
kevin_nisbet wrote: post #147

I'm not commenting too much on the details of the article, but the premise does resonate with me. I would argue all the engineering teams I've been on do not spend enough time thinking about how much a piece of work will cost to execute, and whether it will generate a return. I suspect this is most apparent on things like meeting culture. Something happens and all of a sudden there is another recurring meeting on the…

Meetings aren't even the worst resource wasters. Wrong initiatives, features, apps/platforms/services are. They capture future resources in form of maintenance and complexity with them.

Agreed, and this is where I think some more nuanced and conscious use of tech debt can be used when applicable.

It might be OK to place some bets on an initiative or feature, but if we all understand we're placing a bet, this is an area to load up on debt and really minimize the investment. This also requires an org that is mature about cutting the feature if the bet doesn't materialize, and if the market signal is generated will reinvest in paying down the debt. And also has the mega-danger territory of a weak market signal, where it's not clear if there is market signal or not, so the company doubles down into the weak signal.

Also these bets shouldn't be done in isolation in my view, well executed product and market discovery should also provide lots of relevant context on the ROI.

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

#217

Post by liquid_thyme »

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…

This is true when fresh college grads are building stuff. Experienced engineers know how to build things much more efficiently.

Also people like to fantasize that their project, their API, their little corner of the codebase is special and requires special treatment. And that you simply cant copy the design of someone much more experienced who has already solved the problem 10 years ago. In fact many devs boast about how they solved (resolved) that complex problem.

In other domains - Professional engineers (non-swe) know that there is no shame in simply copying the design for a bridge that is still standing after all those years.

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

#219

Post by wpollock »

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

Earlier quoted context omitted.

> 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 "w…

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

Programming in elementary schools typically involves moving a turtle around on the screen. (My mother taught 4th grade in New York for many years, and I believe her when she explained the computer instruction.)

Economically valueable programming is much more complex than is taught in many schools through freshman college. (I taught programming at the college level from 1980 till I retired in 2020.)

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

#220

Post by 9rx »

wpollock wrote: post #219
9rx wrote: post #209

Earlier quoted context omitted.

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 "w…

> They don't? It is taught in schools in the early elementary level. I see no indication that most are failing. Programming in elementary schools typically involves moving a turtle around on the screen. (My mother taught 4th grade in New York for many years, and I believe her when she explained the computer instruction.) Economically valueable programming is much more complex than is taught in many schools through fr…

Because economically valuable programming has to consider what to program, not simply follow the instructions handed down by a teacher of exactly where and how to move a turtle on the screen. But nobody questions "what to program" not being hard. It was explicitly asserted in the very first comment on this topic as being hard and that has also carried in the comments that have followed.
Post reply on HN