Mastodawn

I'm still baffled by people who claim they can write executable code given a set of vague (or no) requirements, but not executable tests.

"Ah, but Jason, how can I write tests if I don't know what the code's supposed to do?" isn't the slam dunk you think it is

@jasongorman when it's very unclear I like to experiment more though. I typically do write a test, but very high level and typically with a debug statement at the end so I can play around a bit. When I have clearer what I want I throw away (or comment out) my code and rebuild with TDD.

Sometimes this leads to the same code, but more often than not I end up with a better interface

@mark When it's unclear, I talk to my customer 🙂

@jasongorman I've mostly worked in product companies where we can often have a bit more freedom on which way to interpret functional demands. So given a vague description I can search out an implementation which "fits well" in our existing software and verify with business.

@mark I'd do some user research 🙂

@mark But even if I was inventing the requirements myself, I'd usually express the expected outcomes as tests. I find starting with the "what" useful in my design thinking.

Steve Fenton ➜Aug 5, 2023

@mark @jasongorman I do this, too... but usually regret doing it without TDD. I'm building the discipline to throw away the prototype and rebuild it based on what I learned, but test-first so I end up better designed.

@stevefenton @mark I think I've seen @kentbeck talk about this approach.

Steve Fenton ➜Aug 5, 2023

@jasongorman @mark @kentbeck it's one of those "simple but hard" things... when you have something that works, there's a lot to overcome to throw it out! I'm challenging myself to do this on something I wrote recently. This post might give me the leverage over my own fear to get on and do it 🚮

@stevefenton @jasongorman @kentbeck when I was in college I learned that most of the work was in the thinking/discovering/learning and only very little in the code itself.

Mind you, this was no official lesson. In one of my first courses I had to write an XSLT and I didn't know XSLT and it was hard and it was done over the course of two months.

Then my editor asked: "the file has changed on disk, do you want to reload". I thought, sure why not. 1/2

@stevefenton @jasongorman @kentbeck but as it turned out, I was over my quota, so my last save had left the file empty.

I was going to be evaluated in an hour, and I actually was able to reproduce the XSLT in an hour.

This was a surprisingly useful lesson! 2/2

Kent Beck Aug 5, 2023

@stevefenton @jasongorman @mark Ward taught me this one. We had some code that worked but we weren’t happy at the end of the day. He reached over and shut off the machine. I was shocked. The next day we recreated it all better in half an hour.

I'm with *agile*, in that we really only need sufficient "requirements" to do the work that we're about to do. And most of that can be "informal" communication.

(OK; a bit more, for overall project planning and direction, but not much.)

And I go a lot further than that. I hate the word "requirements." I say that it's misleading fiction. We have lots of "want to haves," but very few strict *Requirements*.

…

And I recently noticed that I differ significantly from (at least) common pre-agile assumptions/"knowledge," in that, …

For prototypes, demos, exploratory work, etc., I find that …

*Fewer and less detailed requirements is BETTER!!!*

Like, "Give me some breathing room, man!"

For a quick, throw-away demo or prototype, I want a rough outline, with goals we want to accomplish. *NOT* a detailed field-by-field and attribute-by-attribute Formal Specification, with QA Test Cases, etc

(on Requirements for a prototype or demo, ...)

pre-agile people say
"But you might not have *ALL* the requirements!!!"

I say, "Nonsense!"
"The purpose of this demo is to show that we can add a couple of fields to these vendor-built tables and screens, and enter customer-specific data. The question of precisely what each label text is, exactly how wide each field is (visually), etc, etc, etc, etc, … is mostly time-wasting nonsense."

It's Throw Away code!

George Dinwiddie Aug 5, 2023

@jasongorman
I've used TDD exploratively to determine "how can I use this library I don't yet know to process this input into the results I want?"
I was developing my "requirements" with a vague idea of my desired outcome.

@gdinwiddie I think what's behind it is that a lot of developers struggle to think outcome-first. They're focused in the "how" and don't have the necessary goggles to see the "what" or the "why". It's a general malaise in tech. We're about building solutions, not solving problems.

George Dinwiddie Aug 5, 2023

@jasongorman
To me, it's just a different way of looking at the situation. It's not hard; just novel. Once you've done it, it opens up new possibilities.

A half-step that I've found helpful is using a unit test framework to explore a library or API--calling with known values and asserting that the result is an empty string. This uses the test framework to explore and tell you how that call works.

It's a short step from their to doing similar with your own code.