Break down barriers
Work as a team
Drive out fear
Build quality into the product
Train on the job
Improve constantly and forever
Good ideas never grow old. #deming
6
That being said, I'd be curious to hear your takes on this, and how they may differ from my own experience.
Learning opportunity :-)
1
9
(Taken from the testing google blog)
I'd much rather see a test a bit closer to this, where the test is much less coupled to the implementation of the interactions with the collaborating object.
1
9
I've seen tests like above written both in a "test after" process, where the person felt they were basically rewriting implementation in a testing language or in a test first approach, under the pretence they were doing "outside-in design/specification" (goos style)
1
12
For me, this is a classic example of a test that is highly sensitive(coupled) to the implementation(structure)
kentbeck.github.io/TestDesid…
youtube.com/watch?v=bvRRbWbQ…
1
13
Replying to @AndrewStellman @jitterted
I'm curious:
Do you both consider a test written like this to be testing implementation details or not?
2
13
“La maintenance” by CodingPartner
«Codez comme si les personnes qui effectueront la continuité de ce code sont des personnes chères à vos yeux»
link.medium.com/Tup8CsAfazb
51
"Most conversations about problems (and causes) are negotiations—negotiations about identity, reputation, controlling the narrative, and spheres of influence and control. People look for the "definition" they can live with and process."
cutlefish.substack.com/p/tbm…
29
Replying to @johncutlefish
Owning it. Meaning: doing it without negotiating/delegating the authority to do it with management.
75
Replying to @davidfowl
Hated webforms implementation with a passion, but loved everything I’ve tried my hands on with Blazor so far. Feels like what Webform could have been.
1
1
1,351
Replying to @alexbunardzic @KentBeck
Same could be said for services as a corollary ?🤔
« An awkwardly large service is easier to manage than two awkwardly connected services »?
1
148
Replying to @EskoLuontola @jasongorman
In what cases couldn’t this be resolved by the usage of feature/release flags?
1
1
59
Replying to @codingpartner @jasongorman
Can't blame me for trying!
Sure thing. Thanks for rallying all the troops. We even lost x good men/women along the way....
Anyhow, here is your bonus.
About that new project....
7
Replying to @codingpartner @jasongorman
In scenario B, if they do not meet targets, they fear for their reputation, being blamed, etc. We now go into the(to paraphrase DeMarco) "at least we tried". "We threw everything at the problem: more people, forced overtime, bonuses, tiger teams, etc. and still did not make it.
1
16
Replying to @codingpartner @jasongorman
In scenario A, they are more likely to want to trying different approaches anything, able to see tradeoffs, want to manage scope, etc. Basically, doing what is most likely to make them "win the game." They would be more sensitive to the fact that adding more devs would not help.
1
82
Replying to @jasongorman
Simplified version of how I've come to view it.
It depends if the manager's incentive are aligned A) most towards delivering the outcomes or B) to preserve their reputation.
1
1
546
Replying to @jasongorman
I've seen this with even with devs with 10-15 years experience. Unfortunately, sometimes, they've just yet to meet/pair with anyone who will show them better.
1
1
661




