269 karma · joined April 8, 2016
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.
Let me know if anyone has a recommendation.
Funnily enough though (and this might just be my lack of skill in iOS development) I always find the UIKit components surprisingly tough to customize.
Every time I work on something I try to learn to think like the user, at least a bit. I even had to learn the basics of coal mining once. You could say it was a waste of time for a programmer to learn coal mining. But, it Saved countless hours of misunderstanding and wasted time.
Second best option is when your product owner is a user.
Then all the other approaches are even last place. Imperfect solutions to a problem id rather not have.
Like any tool, Lean Startup MVPs aren’t the right tool for every situation. You need extreme uncertainty.
If you’re a FAANG and you’re releasing a new version of a well established type of product like an email client, what giant existential risks do you have? FAANG have existing customers, we all know people use email. There’s no questions to answer, no uncertainty, so MVPs are the wrong tool for the job.
Why bother running experiments if we have 20 years of data showing us that we have customers and they like using email…
In Lean Startup, Eric Ries argues that if your business has giant unknowns. Big leap of faith assumptions. Then you’re best off using the scientific process to validate those unknowns before you do anything else. Start with a theory, design experiments and analyse the results. Repeat.
The MVP is the experiment. It’s a pity that he didn’t call it “quickest experiment”, because that’s what a Lean Startup MVP is, just the quickest experiment you can use to validate your businesses assumptions. And how can using a “quickest experiment” be old and broken? It’s a perfectly valid approach sometimes.
The other common use of the term MVP is to ruthlessly cull a products features before the first release. To find the MINIMUM PRODUCT that would be VIABLE. People use the term that way because that’s what it sounds like an MVP would be. And again… it’s a perfectly valid approach. How could it be old and broken to pragmatically limit the scope of a first release to the minimum set of features that users find viable so that you can keep as much time as possible for responding to change.
Anyway, I think the two kinds of MVPs are still good tools in the right hands when used in the right situations. I’d hate to throw away good tools just because they don’t work in every possible situation.