Comment by wonderwonder | Hacker News Reader

Comment by wonderwonder | Hacker News Reader

Parent Full thread

Software companies with sufficient market share take on an almost zombie like quality. No matter how much damage they take internally they are able to continue lurching forward and making money because there is no one else in the space that is a viable option or they have their customers locked into expensive contracts. I worked at one such company for a few years. It was terrible. The software was garbage and management was truly awful. We were required to hit 10 ticket points each week or pipped. The only way to do so was to work 60+ hours. I got pipped for the first time (~18 months in) when during the first month of covid lockdowns I got 8 instead of the required 10 points. They literally could not understand how I might have distractions going on due to a brand new pandemic, my kids and wife suddenly being home and lockdown.

Whatever decision you made they yelled at you. I got yelled at once for not lying to a government official. When I quit, every sr. developer quit within 3 months of me; 7 total left and left behind 6 non sr. devs. This was 3 years ago. The company is hemorrhaging money but just keeps issuing more stock to stay afloat. It used the money from that stock to buy its competition in a very niche market and essentially just put them out of business. So they survive and lurch on.

> Software companies with sufficient market share take on an almost zombie like quality. No matter how much damage they take internally they are able to continue lurching forward and making money because there is no one else in the space that is a viable option or they have their customers locked into expensive contracts.

/Softwarecompanies/Some companies/g

I wrote a paper for an assignment (maybe ten years ago, ask me for a link, and I'll see if I still have it), in which I called this phenomenon Corporate Inertia, and it isn't only applicable to software companies.

Sometimes the inertia is good - it allows the company to weather bad times.

Other times the inertia is bad, because the company cannot pivot in time to address new challenges or take advantage of new opportunities.

Mostly, the good outweighs the bad - if a company cannot pivot in time because it is so large, it merely buys the smaller company that verified the idea already.

I’ve always described this as “Rome didn’t burn in a day.”

> Software companies with sufficient market share take on an almost zombie like quality.

+100.

Booking.com and JIRA come to my mind as good examples. Just about everyone complain about Booking, customers, engineers working there, hoteliers etc., Yet it continues on. I hear they've been trying to migrate to a modern tech stack for years but to no avail.

Because most of the competition manages to either be worse than them, or lack the features that actually make them relevant.

I am reaching 50 years old and am yet to see any ticket management system that is as powerful as Jira, while offering a relatively good usability story, and the integration story of having a ticket bind to documentation on confluence, SCM related history and CI/CD reports.

Likewise the competition to Booking usually fails to show as many properties, have as rich filter selection, and in many cases their prices are higher than what Booking offers, moreso if one happens to have Genie level status.

Saying this as not a jira fan but realizing it has its place.

The irony of jira is the years it takes to realize how few pieces of software can soak into complexity like it can.

The pain of jira is how it largely can’t universally handle complexity out of the box or how you’ll find yourself in it - how it must be actually setup for your use case - how much it benefits from being setup by someone who has experiences with the pros and cons of cocaine one of the many ways of doing something.

The new project type (team?) is a step forward to start with from scratch. But a kiss of death if you need to outgrow it for some features that aren’t there yet.

Work management is a custom problem, that no generalized solution will fit.

Unless you're a mega corp - you're not getting a good work management solution.

> We were required to hit 10 ticket points each week or pipped.

I ask about ‘points’ in interviews, its an immediate stoppage for me

Yes, that's very important. I made the mistake of taking a job where they were into full blown "planning poker" nonsense. It was hell. "Is this a 2 or a 3?" The discussion could go on for ages. "This can't be an 8! Can we break down this into a 5 and a 3 point ticket?" No estimate was allowed to be an 8. I better stop, since I'm having flashbacks...

Hah I got in trouble once for just going through a grab bag of bugs from our designer (mostly trivial CSS issues) and fixing them. My manager got upset because the tickets never got their costs estimated, and I never put them in jira. (Even though the “3, 5 or 8” conversation would have taken more engineer time than just fixing the bugs directly).

I asked him why he was so upset. Eventually he admitted that closing tickets in jira was how upper management measured how well our team was doing - and by extension him. I thought that sounded like his problem and still refused to put the issues in jira. So he did it - meticulously creating a couple dozen issues, making up a BS point estimation and closing them all as complete.

Whenever I think about bullshit jobs, I think about those silly cost estimation cards, that guy, and how deeply satisfying it was that day just diving in and making our product actually better.

Tickets can also be some documentation about why some code is why it is. Put the ticket number in your commit message and use git blame when you want to understand something better. By fixing code without tickets you make this impossible for future developers.

Yes tracability etc... but to be honest: For such a trivial thing, this thing called commit message right before or after the ticket reference can do the job as well with one less indirection ;)

This is any-benefit thinking.

There is some tiny marginal benefit to what you’re talking about (there’s a chance someone might later want to look at the corresponding issue). But you aren’t acknowledging the cost, measured in my sanity making a bunch of one-line issues in jira, and the team’s time doing cost estimation.

It’s nice to leave breadcrumbs for future code historians. But our job is shipping product. Cost estimation, jira, etc all only have value proportional to how much they help us ship. If the meetings are pointless, and jira isn’t needed then doing that anyway is a waste of time.

“Link to a ticket system” is generally awful advice.

- Why the commit was made should be in the commit message

- What the change is inherently lives in the diff

- Why the code is how it is should be in comments adjacent to the relevant code item.

To be fair if the fixes are trivial they shouldn't need any extra context from a ticket to understand

I remember the endless Scrum meetings where we debated points with all the seriousness of medieval monks discussing how many angels could dance on the head of a pin. As a rough heuristic points aren't bad, per se, and they are a bit better than straight time estimates.

But when they become the subject of endless meetings it's a tell that maybe the company has hired too many people too quickly and is in the "bullshit jobs" phase where it's happy to waste precious salaried hours on meaningless debate.

Quite standard in any big corporation.

You're lucky not having been discussing money budget per ticket instead.

I have had projects where sprints got money budgets assigned to them, which divided by the cost per hour of each developer got us the amount of hours available for the sprint.

Those hours were the budget for the sprint, no more no less, better chose wisely the stories that fit in.

To make it even better, some project activities only were given such kind of budgets in specific times of the year, then one of the external consulting partners would have the go at that specific sprint.

So not only were the tickets chosen to fit the budget, every few couple of months, the teams doing the work were always rotating.

Hmm every job I have had uses points this way. I find points discussions particularly mind numbing and have no love for them but I also can see the utility. What is the alternative?

When it ceases to be a useful tool to stay organized, and becomes a burden, it's very frustrating. The alternative is to use the tool when it helps you and ignore it when it's not.

I guess it depends on the clarity of the work and quality of the facilitator.

I have had your experience with poorly organized PM and horror stories during sprints...

And I had the best planning sessions with a proficient PM, that made picking up tickets a marvellous pleasure.

What is the exact Q you're asking? I'm genuinely interested.

I ask about development practices, I have them describe how they approach features, tech debt, planning, attribution, interruptions, and so on. Somewhere in there Ill ask for an example and ask some precise questions and then also about points, so they dont think Im overly focused on that exact aspect

Reply on news.ycombinator.com