What matters?

Could we maybe stop fomenting hatred?
Could we maybe start calling it out as wring?

1/2
What doesn't matter?

Dungeon 124
I want to get a creature to lead us to the WayDown. And I feel the need to improve the campground. Also St. Gertude. And, as often happens, we don't go where I expect. Neat outcome, though
ronjeffries.com/articles/020-d…

2/2
Yes, I see a typo. Will fix. If you see two different ones, let me know.

3/2
grr. wrong.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ron Jeffries

Ron Jeffries Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @RonJeffries

21 Feb 20
while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve.
Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.
XP doesn't really contemplate separate testing. Like Scrum, at the end of the iteration, the "programmers" deliver a working tested integrated version of the product. N.B. tested.
Read 12 tweets
22 Jan 20
The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9
As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9
You're supposed to look up when the rumble strip rumbles, and think about how you got off the road. You're supposed to survive hitting the guard rail, to think about maybe slowing down for curves.

3/9
Read 9 tweets
18 Jan 20
OK, strong article to follow but for now, listen up.
There's this idea, the red/green/refactor thing, the never write a line of code not required by a failing test thing, the evolve the design based on the test and code plus your lovely imagination thing, the keep it clean thing.
I say "idea". You can see many ideas there already.

There is a name, TDD, Test-Driven Development or Test-Driven Design, that is applied to that bunch of ideas. We want to draw a bright line around the ideas that /are/ TDD, and to keep out the ones that are not TDD.
Yeah, no, we can't do that. Ideas are mushy and they flow one into another and they smear all over each other, and they change from something sensible to something stupid right before your eyes.

Still, we'd like to do that and for now I'll try to do that.
Read 19 tweets
31 Dec 19
I'm writing a thing about what it feels like to do TDD, in a kind of response to the articles and remarks by @jcoplien and @dhh and others. I agree, of course, that 100% line coverage, which you get for free with TDD, doesn't mean much in a theoretical sense.

1/6
Even 100% branch coverage doesn't mean much. While I don't subscribe to all the math in Cope's article, it's true that, theoretically, a program with high coverage can include plenty of errors.

What's interesting is that in practice, theory doesn't quite work.

2/6
If you TDD some little thing, making sure that every line of code you write is required by a meaningful test, and get it working, try this experiment.

Look at the code. Try to find places where a change to one or more lines will break the program but not break the tests.

3/6
Read 6 tweets
26 Dec 19
Well, I was going to write about "Doing it wrong" today, but it turns out that I already have. This article isn't quite what I'd say today but it's close:

ronjeffries.com/articles/019-0…

1/12
What would I say today that's different? Well, I'd clarify that there are at least three main ways that a TDD that doesn't work could differ from one that does:

- different design style.
- different problem: "TDD doesn't work here"
- different thing: "not TDD"

2/12
TDD favors a design style that leads to lots of very small, encapsulated items: classes, methods, functions.

If your preferred design style doesn't lean that way, you'll likely find TDD to be of less value.

3/12
Read 12 tweets
23 Dec 19
But seriously, here are a number of ways in which mastering Scrum is difficult ...

1/5
Creating a good backlog is difficult to master (DTM), especially since it's best to backlog problems, not solutions or stories.

Sprint Planning is DTM because it works best as a collaborative meeting, not a PO tells team what to do meeting.

2/5
Dev Team is DTM because there are strong forces militating against true cross-functional teams.

Development in Sprints is difficult to master. I hope that's bloody obvious.

3/5
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!