News for hackers. Stuff that matters.
Re:The art of interrupting software engineers by _betty_ on Tuesday July 30, 2019 @04:32AM (#20563076)
I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature.

This practice is just saving time writing down behaviour that won't be implemented.

Re:The art of interrupting software engineers by afarrell on Tuesday July 30, 2019 @08:13AM (#20564089)
But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction?

What do you do when people forget things?

Re:The art of interrupting software engineers by _betty_ on Tuesday July 30, 2019 @05:08PM (#20569184)
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.

There's still something written down, just not massive amounts.

Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.

Otherwise I just communicate a lot.

Things get differently from what I invisioned, sometimes they're worse sometimes they're better.

Re:The art of interrupting software engineers by peteradio on Tuesday July 30, 2019 @09:39AM (#20564715)
You artfully interrupt them and always keep watch on what other people are doing!