Comments URL: https://news.ycombinator.com/item?id=45636114

Points: 2

# Comments: 0

Our team is building blast design and simulation software. Our tech stack is 100% pure rust. We have a pile of interesting problems to solve: building elegant UX, 3d rendering complex surfaces, simulating explosions, etc.

Really nice team, fully remote (from anywhere in Australia).

Follow the link to apply: https://www.seek.com.au/job/81661361

How a common bug was rolled out globally with no controls, testing, or rollback strategy is the right question

I just don’t use the word Agile. Too many people like it for the wrong reasons, or hate it for the wrong reasons. Everyone has a different understanding of it. It’s just not useful.

If I say “let’s use Agile” it’s just going to lead to arguments and misunderstandings.

Id always rather be more specific about which Agile idea I think will be useful. E.g. “let’s build a prototype before we waste time planning too much detail” or “lets get something built and released so we can learn more about what our customers want” etc.

For example, a backlog is a priority queue. A priority queue can only be long if work is added more frequently than it is removed.

Work can be removed if it is either completed or abandoned.

Work can be added when users request features, users find bugs, product owners predict features will be useful, or the dev team adds technical improvements.

Talking to users will increase the bugs identified and the user requested features.

So by these relationships, talking to customers will directly increase the size of the backlog.

And the overall backlog length may be large due to many factors unrelated to talking to customers: slow development, never deleting out of date work, adding too many technical tasks, adding too much unvalidated vision work, etc.

Does anyone know of any books, blogs or youtubers that bring this kind of logical system level thinking to software work management?

    1. Variable viewer so I can see the current value of all variables in scope. 
    
    2. Interactive debugger

Any plan to add debugging?

Also this quote is amazing

    “the authors state that “no datasets were generated or analyzed during the current study””

Every other UI framework or library that I’ve used felt like leaky abstractions. You always have to learn both how the library works AND how css works.

Tailwind isn’t even an abstraction, it’s just a layer of convenience to be used where helpful and ignored where not. The thing I love about Tailwind is that it feels like CSS. In fact, I feel like I know CSS better for having used Tailwind.

How would a potential customer of SAFe see it?

Right now somewhere in the world there is probably a C level exec of a large org reading a powerpoint about how transformative and agile SAFe is. They’re probably in their mid fifties and have never worked in tech before. They know agile is good, but any large IT project is risky.

What would they see if they read this? Would it mean anything to them? Or would they see a bunch names they don’t recognise, and a list of failed IT projects blaming SAFe.

1) You said you can't manage this team directly. Is it your responsibility to make this team successful? I know it's annoying to see a team with horrible code and who refuse to change. But is your manager expecting you personally to fix this? If not, just leave it.

2) Even if it's your responsibility, is this where you want to spend your time? As a leader you have limited time, energy and political capital. You need to decide strategically where to spend that time to have the best impact on your company and to achieve your personal career goals. The fact that you can't manage them directly makes me think that they're not your only job. If it's just one area of your responsibilities, I'd consider letting this team continue to fail and focus on other areas where you can make some wins.

3) Is how the business views this team wrong? They're making a lot of revenue with a very cheap team who seem to be very focussed on delivering results. Yes I know, it's annoying. They're doing everything wrong and their code is unimaginably dirty. But... They're making money, getting results and neither they nor the business see any problem. So again... should you just let it be?

4) Ok, so if you're absolutely committed that this code base has to be fixed... maybe you should just find a different job? Either in the same company or in a different company.

5) Ok, so it's your problem, you want to solve it and you're unwilling to leave. What do you do?

Well, anyone can make a list of ways to make the code better. Because this team has been doing everything perfectly wrong, it's not hard to find ways to improve: source control, automated testing, CI/CD, modern libraries, SOLID, clean architecture, etc, etc.

You can't quietly make the changes, because the team doesn't agree with you. And even if they did, this hot mess is way past the point of small fixes. You need to put in some solid work to fix it.

So you need buy in from management. You either need to deliver less while you improve the code base or spend more money on building a larger team. But since they see no problem, getting their buy in won't be easy.

Try to find allies, make a pitch, frame the problem in business terms so they understand. Focus on security risks and reputational risks. And don't give up. You may not convince them today, but if you make a pitch, they will remember in 6 months time, when this team is still floundering. They will remember that you were the person who had the answers. And then, they may come back and give you the time and resources you need to clean up the code base.

So in conclusion. If it's not your problem, ignore it. If you have other teams to manage that aren't a mess, focus on them and let this one fail. If you're going to be responsible for this pending disaster, quit. If you absolutely insist on making a change, start with getting buy in from management. Then incrementally work down the technical debt.

Plus it’s strangely addictive.

The creator even wrote a blog post describing how he made it. Press info on the top right to get an awesome breakdown of his approach.

Funnily enough, I actually wrote this post because if you had asked me about cross platform web apps 6 months ago I would have said the exact same thing you just said.

In 2014 I'd started an app using Ionic and actually ended up abandoning it and it killed the project. I was so frustrated. That's why I was shocked with this app (and yes it is small and pretty simple) actually worked really nicely being a react app bundled into a webview. It's crazy, I was just shocked.

Made me realize that cross platform web apps are a hell of a lot more capable today than I had thought.

And sure, maybe claiming native apps will die eventually is a pretty bold claim... But technology moves. And the direction it's going now, is in the direction of browsers becoming faster and more capable at a greater rate than user's desire for more elaborate UIs. Visual Basic and Java used to be the hottest tech you could have on your resume. Who knows what will be old fashioned and out of date in the future.

I don't normally make bold claims but I think I'll stick with this one and maybe in 5-10 years I can fish out this blog post to see if I'm right or not.