- take a blank piece of paper (this is “the software”)
- pick two random points on the paper roughly 3 inches apart (“a requirement”)
- draw a line between the two points; the line cannot cross any other line (“the implementation”).
Repeat the exercise multiple times.
You’ll quickly learn that unless you have a “system”, drawing a three inch line goes from taking about 2 seconds, to taking 10, 15 or 30 seconds, despite “the requirement complexity” being exactly the same every time.
Now try playing with people taking turns. :)
I like playing this game with people who think that writing bad code is fine, or that they can work by themselves and not worry about what other people do as long as “their own” code is good.
You can still solve pretty much any problem with enough time and effort; but if you don’t have a “system” for good organisation, eventually, you’ll be struggling to solve basic problems because of layered unmanageable requirements, no matter how smart or capable you are.
…it’s not about shipping bugs, it’s about fundamentally reducing the speed of delivery over time, incrementally, in an unbounded fashion that eventually makes systems impossible to make changes to without compromising on requirements.
(Obviously the game is contrived, but it works very well in explaining why past requirements some times have to go away to business people in my experience).
What "system" would you use for random "requirements" (dots on a piece of paper)? The only reasonable thing to do is to push back on "requirements" that don't fit into the existing requirements/software/implementation.
The thing about this game is that there is no requirement that is technically impossible.
That's provable; with no closed loops, any pair of points on the paper can be joined by a long enough line. That's why it's a good analogy for code.
...but if you, eg. a system for this; Use straight lines only and space the lines equidistant from other lines.
I mean, it's a game. Literally play the game a few times (grab a friend and do it together) and you'll very quickly figure out things that do work (leaving space) and dont work (draw crazy squiggly lines and lines that are too close together).
This is just a contrived example; if you want to make it more realistic allow 'you can erase a line and redraw it as long as the requirement is maintained', and then you can structure lines into groups, etc.
Ah, so you are pushing back on the requirements. "I'm not going to implement the requirement (two random dots added) as it would break my requirement to only have straight lines in my implementation."
- take a blank piece of paper (this is “the software”)
- pick two random points on the paper roughly 3 inches apart (“a requirement”)
- draw a line between the two points; the line cannot cross any other line (“the implementation”).
Repeat the exercise multiple times.
You’ll quickly learn that unless you have a “system”, drawing a three inch line goes from taking about 2 seconds, to taking 10, 15 or 30 seconds, despite “the requirement complexity” being exactly the same every time.
Now try playing with people taking turns. :)
I like playing this game with people who think that writing bad code is fine, or that they can work by themselves and not worry about what other people do as long as “their own” code is good.
You can still solve pretty much any problem with enough time and effort; but if you don’t have a “system” for good organisation, eventually, you’ll be struggling to solve basic problems because of layered unmanageable requirements, no matter how smart or capable you are.
…it’s not about shipping bugs, it’s about fundamentally reducing the speed of delivery over time, incrementally, in an unbounded fashion that eventually makes systems impossible to make changes to without compromising on requirements.
(Obviously the game is contrived, but it works very well in explaining why past requirements some times have to go away to business people in my experience).