Gergely Orosz

A mistake less experienced software engineers make when it comes to estimations:

They break out maintainability/quality. Eg “building the feature is 2 weeks, adding automated tests another 3 days”.

What follows by less technical stakeholders is a push to remove the latter.

Non-functional requirements like correctness, quality, maintainability, performance etc should be baked into estimates, and not made part of bargaining. That bargaining is how sw can become less maintainable over time.

Feb 26, 2023 at 3:13pmWeb
Show threadAndré BeckerFeb 26, 2023
@gergelyorosz Also: Insist on "push to prod" not being regarded as the end of the project. Plan for a post release validation phase with its own deliverables.
Show threadJoel ChippindaleFeb 26, 2023
@gergelyorosz I think you've put it much more concisely than me 😀
https://blog.mocoso.co.uk/talks/2020/02/27/take-control-of-code-quality/
Take control of your code quality

Your browser does not support the video tag - you can view/download this video at https://assets.lrug.org/videos/2020/april/joel-chippindal...

Show threadJRFeb 26, 2023

@gergelyorosz Quality is part of scope. Who has the authority to change scope? Product management, not devs.

Theoretically a "definition of done" explicitly invoked in the estimation phase deals with this. That said, my experience with a "hard" DoD has been mixed.

Show threadBarrettFeb 26, 2023
@rodley @gergelyorosz concur with the statement that quality is part of scope, as a PO . As a dev, though, I see a ton of POs that don’t understand enough about the dev process to make informed decisions about quality.
Show threadJRFeb 26, 2023
@ba66e77 @gergelyorosz
That's why people resort to a "hard" DoD. We only ship stories of a known quality. You want to reduce scope, use feature-scope, not quality-scope.
Show threadSiena AguayoFeb 26, 2023
@gergelyorosz amen. I tell engineers to just write the tests, don't ask for permission to write the tests.
Show threadHobson LaneFeb 26, 2023
@gergelyorosz and it will accelerate development and creativity if things like automated testing and monitoring are built first. You can't improve what your don't see (measure)
Show threadTiago EspinhaFeb 26, 2023

@gergelyorosz sadly this happens even with extremely technical stakeholders.

And it’s made even worse because even if you make testing part of the estimate, those technical stakeholders know this and will actively cut down on the estimate by dropping tests “to the minimum that gives us confidence that the feature works”, whatever that means.

Said stakeholders are also all too happy to hold *others* to account when sh&t hits the fan. “How come we didn’t test this?!” Uhhh 🙄

Show threadBilly O'NealFeb 26, 2023
@gergelyorosz indeed. Only took the bait and switch a few times to realize I can never submit for review anything I wouldn't inflict on customers, because "it's just a prototype" very quickly becomes "so when is it shipping"
Show threadBishoFeb 26, 2023
@gergelyorosz plus it should not be an after thought. Programming it for a second phase means you are not considering it during the design phase.
Show threadDaniel GibsonFeb 26, 2023
@gergelyorosz @TTimo
s/less experienced software engineer/less experienced manager/
Show threadTTimoFeb 26, 2023
@Doomed_Daniel @gergelyorosz I mean .. Software estimation is a bit of a black art. It's hard enough and inaccurate when you are the one writing the software .. I don't think PMs should do it .. Other than gathering and adding up what their guys are telling them maybe.
Show threadDaniel GibsonFeb 26, 2023
@TTimo @gergelyorosz
I mean that manager should explicitly plan time for writing tests (and demand them) instead of seeing them as a waste of time.
It shouldn't be up to developers to "secretly" write tests because they officially don't get time for them
Show threadDaniel GibsonFeb 27, 2023
@TTimo @gergelyorosz
(Of course I agree that the time estimates themselves should come from the developers, but secretly extending the scope of the task because the managers make poor decisions doesn't sound very healthy)
Show threadSandip BhattacharyaFeb 26, 2023
@gergelyorosz
Imagine what these people will do if you tell them that LOC for tests (and accompanying infra) can sometimes be as much or more than the main code
Show threadMeesterfoxFeb 26, 2023
@gergelyorosz If you're working somewhere that 3 days of test writing risks getting cut from a project thats taking 2 weeks, that's not an estimate or communication problem, but a culture and process one.
Show threadJon JenningsFeb 26, 2023
@gergelyorosz I argue the opposite.
I break out quality-related bullet points (even though you and I know that quality IS baked-in throughout the whole process) because that shows that it's a thing we've considered and that doing things right takes time.
However I don't negotiate on those bullet points. You can cut features etc but the quality elements are mandatory.
When there's pressure to shorten them it makes for a deliciously awkward conversation 😁
Show threadIain GallowayFeb 27, 2023

@gergelyorosz I'm always having to balance a) giving my clients what they ask for, knowing that I don't always have the big picture; and b) pushing back on my clients, knowing that they aren't the experts in how good software gets made - otherwise they wouldn't need me.

Sometimes a hacky prototype is actually what the client needs right now.

Show threadErwin Rossen 🔸Feb 27, 2023

@gergelyorosz How can you even build something without writing automatic test cases? You have to test anyway, the fastest way to do that is to automate it (in general, exceptions do apply).

As a software engineer, I would therefore phrase the estimation like this: "If I have to build it without automatic test cases, it will cost me 3 weeks before it works. If I have to build it with automatic test cases, it will cost me 3 weeks before it works."

Show threadErwin Rossen 🔸Feb 27, 2023
@gergelyorosz In my experience, the main reason for wrong estimates is not forgetting to plan non-functional requirements, but that we only plan the knowns, not the unknowns. In any project one will encounter things one didn't anticipate. We should plan time for that.
Show threadRay Ryan (he/him)Mar 1, 2023
@gergelyorosz The penalty is MUCH higher than two days.
Show threadDeezy.exe stopped unexpectedlyMar 1, 2023
@gergelyorosz
I always have to impress on our production team that it's not just engineering effort. There's a *lot* of effort around the core engineering too.
The "taxes" that need to be paid before something comes collecting, and they *will* come collecting.