Originally published at: https://boingboing.net/2018/12/26/fizzbuzz.html
…
1 Like
This should make an awesome drinking game.
2 Likes
This is evil, but it’s not teaching TDD at all. The whole point of TDD is that your tests are constantly failing: every new feature you want to add begins with a test, and you know you’ve done the feature when the test passes.
A formulation which would work:
The team loses if they ever have a green pass when a test is first written. If you write a feature without a test, how can you be sure the feature works? The test at the end is that the person running the game has to examine your test suite. 1: you have to be green, and 2: the instructor can’t think of any more tests. Every test they can think of which is relevant is a point on you, golf style. As a variant, make it a half point if your program passes the test when the “missing” test is written.
4 Likes
I can remember back in my College days, when I was getting my degree in Computer Science and Software Development before the turn of the millennium, we designed software by asking the users what they want, then built a solution which was designed around those requirements. Which is a better way of building software, but it comes at the price of users actually knowing what they want.
Now, we design software so that when it fails because the users don’t know what they want, at least something will be useful. It’s like not designing an airplane to fly, but to fall, with style.
We need better Business Process Analysts, not better ways of failing.
5 Likes
There is definitely a fantasy built into every design paradigm that if we just follow this set of rules, our software will be good.
In a way, this was terrible lie that was sold to Generation X generally by our Boomer parents, along with the dreadful “follow your bliss”.
1 Like
Bottoms up!
3 Likes
When we played this back in elementary school every number that contained the digit 3/5 was another fizz/buzz: 11, 12, fizz, 14, fizzbuzz … 28, 29, fizz, fizz, fizz, fizz, fizzbuzz…
really challenging!
1 Like
Based on reading the twitter thread that suggests this (really, there has to be a better way to distribute an idea like this than a bunch of 280-character twits), it isn’t quite as pointless as you suggest. It isn’t teaching TDD, I’ll agree, but it isn’t as bad as you suggest.
The key is that this is an exercise in working as a team, with the FizzBuzz as a stand-in for a full project. You are required to have version control and continuous integration. The “always green” requirement is on the CI system, not on the individual developer’s machine.
In a TDD fashion, the cycle is test-red-code-green-refactor-green, at which point you can merge and push. You don’t want it to go red on the push.
The “evil” part of this, in my opinion, is the requirement that the five bits are treated as separate “features” to be worked on by a separate developer/pair. The stories are not “thin vertical slices” – none of them are fully usable, but partial, end-to-end solutions. It’s a hard exercise, especially with the 1-hour time-limit, and the requirements to work as a team from scratch, but while the poor stories may be realistic, they don’t teach good agile development process.
4 Likes
I played a version that replaced multiples of 5 with prime numbers and was named Blatz. If you fucked up you had to drink Blatz. Would recommend.
1 Like
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
