(no title)
monch1962 | 3 years ago
When I focus on building a really flaky version of a thing as quickly as possible, then I quickly land on all the edge cases and more-complex-than-I-thought areas I need to deal with.
Sometimes I can refactor my flaky code to deal with those, but more often than not it's easier and faster to just throw it away and start again with my new-and-improved knowledge of what needs to be done.
The challenge is then (a) working out how far to go down the quick-but-flaky path before starting over, (b) working out whether to keep sections of that flaky code or rewrite it, and (c) trying to not get scrum masters over-excited that I built a barely-working thing in 1 day when the working-well thing is still a week away
anoopelias|3 years ago
One way to do address this is - to be explicit about the flakiness of the work by marking it as a spike story[1]
While this is less than ideal, it is a formal way to get the message across.
[1] https://www.agile-academy.com/en/agile-dictionary/spike/