The other day we designed a process to match cleared deposits with dispensations. This is how I would have white-boarded it a few years ago:
Since then I've played around with functional programming. It encourages one to think about processing in terms of data streams: data comes in, gets transformed and filtered and manipulated, and finally results are output. Not only do programs work this way, but each piece of the program -- each function -- is also modeled as data in, data out. No state changes in the middle.Thinking about the problem in this way leads to this kind of diagram:
Whatever language we use to write the solution, thinking about it this way has the following advantages:
* It breaks down into pieces. (The orange boxes represent JIRA tasks.) The requirements are already specified on the diagram: what goes in, what comes out. Each task can be developed independently.
* Each bit is testable. The database-impacting pieces are called out; other than that, each box is defined entirely by input and output. That's the easiest kind of component to test.
In this way, thinking functionally helps with agile (task breakdown), TDD, and maintainability. The code is more composable. Thinking about the problem is easier because we can see what the data looks like at each step.
Independent, testable components: that's functional.
For how functional thinking helps at a lower level too, check this post.
New coding tricks are fun, but new white board techniques are serious business.