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

71–80 of 96 posts

Re: What factors explain the nature of software?

#71

Post by naasking »

a_c wrote: post #21
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.

> Customer got their features faster.

Did they though?

Re: What factors explain the nature of software?

#72

Post by ryandrake »

ak_111 wrote: post #62
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 have a meta question here, am always curious when seemingly competent engineer such as yourself put up with this kind of management. It is unbearable to work for someone who doesn't appreciate your work let alone belittles truly hard-earned achievements, for example that statement when he demanded you get 4000% rather than 2000% that you achieved would have made me quit on the spot. Further from the sounds of it th…

Not OP, but I worked for a similar founder. The only work he wanted software engineers to do was writing code, and not just that... only 1. code that added a customer visible feature or 2. code that fixed a major, customer-facing bug that a customer actually complained about. Fixes for bugs not discovered by customers? No. Performance improvements? No, not even visible ones. Refactorings? No. Technical debt cleanup? No. Build speedups? No. Update the code to work on a recent compiler? No. It gets better! Version control? No. Bug tracker? No. Unit tests? No. I had to implement the above three on my free time. Standing up dedicated build and test infrastructure? LOL get real. Eventually, I was able to argue for a few of these, but it was always a fight.

The reason I stayed was that the hiring market is not always that great, and it tends to be much harder to find a new job than HN would have you believe. This idea that most of us can simply "walk into any" company and get a job is fiction in all but the hottest job markets.

Re: What factors explain the nature of software?

#73

Post by jiggawatts »

bluefirebrand wrote: post #12
spit2wind wrote: post #9

Earlier quoted context omitted.

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

I’m stealing that quote for my own purposes. I hope you don’t mind.

Re: What factors explain the nature of software?

#74

Post by ryandrake »

skydhash wrote: post #56
TheAceOfHearts wrote: post #15

Earlier quoted context omitted.

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 platform owners could so a lot to ease this burden, but everyone wants their own little fiefdom. The thing is that most people use one platform. So the owners try to present one consistent view on how to use that platform. Trying to provide a common paradigm across platform is the goal of companies that love their brands too much. But as a user, I just want for everything to function similarly so I don't have t…

I don't know where this idea came from that an application should look and feel exactly the same across Windows, Mac, Linux, iOS, Android, and so on. I have encountered this attitude in more than one company, but have not heard of any actual customer who wants this. As an actual computer user, the worst applications tend to be the ones that stick out like a sore thumb by ignoring OS conventions and using custom-drawn controls with nonstandard behavior.

Re: What factors explain the nature of software?

#75

Post by jsrcout »

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.

A friend calls it the Logjam Principle. There are always a few logs floating down the river and that's not really a problem. But a small logjam of just a few logs will grow over time until the entire river is obstructed. It's better not to let things get to that state.

Re: What factors explain the nature of software?

#76

Post by titzer »

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

" ...a new (often anticipatable) requirement seems to appear... " And often not, particularly when you are building a new system. And if you are replacing an existing system, the requirements that you discover are usually, "it must work exactly the same way as the old system."

If you're replacing an old system, a great piece of documentation is the original requirements against which it was built, especially if that document is versioned. Goes a long way to understanding why something was built a certain way and whether the new thing can do the job of the old thing. It's so much better than something either overly vague or overly specific like "it must work (exactly) the same way as the old system".

Re: What factors explain the nature of software?

#77

Post by bmitc »

esafak wrote: post #31
bmitc wrote: post #4

Earlier quoted context omitted.

What is The Cathedral and the Bazaar about? I couldn't quite tell from a cursory glance.

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

Yea, but I guess I was looking for something deeper, because at the outset, I'd be a little offput by the suggestion to read it and any disagreement about my disagreement on it. And I fully understand the issues described by the above parent. The book comes off as a bit opinionated with the blinders of a Linux kernel development and 80-90s attitude about open source software. That's a pretty narrow focus of software development.

For example:

> Every good work of software starts by scratching a developer's personal itch.

I've written good software professionally, but none of it was kickstarted by my own personal itch.

Re: What factors explain the nature of software?

#78

Post by chriscbr »

a_c wrote: post #41
jprete wrote: post #32

Earlier quoted context omitted.

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

This is blatant conservatism, and it's a mentality which leads to dead players. The job of an executive is to make good decisions; it's in the name: execut-ive. To decide always in the direction of the existent culture is a very peculiar bias which is only successful in certain situations.

Re: What factors explain the nature of software?

#79

Post by q7xvh97o2pDhNrh »

bluefirebrand wrote: post #12
spit2wind wrote: post #9

Earlier quoted context omitted.

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

What you really need to do is schedule daily status meetings, a longer weekly status meeting, and -- this is the real velocity trick -- monthly OKR reviews as well as quarterly slide presentations.

It's important the slide deck be polished for all the people who want to come learn about the project, so it makes sense to spend at least a month preparing it.

And the neat thing is that all this work will get you lots of suggestions from executives about how you could address all the velocity issues that your project seems to have all the time! So you'd better budget 2-4 weeks after the presentation to follow up, have stakeholder meetings, and make sure everyone really feels heard.

With just these few simple techniques, you too can get your engineers moving at the blinding speed of an average FAANG engineering team.

Re: What factors explain the nature of software?

#80

Post by jacobross »

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

I have to preface my comment by saying I am reasonably technical but not an engineer by any stretch. I find this comment fascinating and it seems to highlight some issues I face in my own organisation (tech/design professional services company). We build apps and platforms for enterprise clients and often struggle with predicting a lot of parts of our software.

I might have a poor understanding of your comment but could you expand on the ideas behind solvers and what they are? What data do they ingest from a company building software and how did the solver you build work (in layman's terms)?

Thank-you!

Post reply on HN