I was just updating my Example UML Use Case diagram article and it occurred to me that if you're a Business Analyst, there are a couple of questions you can ask yourself as you write a Use Case (or User Story) that will help improve the quality of your writing. Two questions specifically come to mind:
- What are the main points of this use case? (Which might also be phrased, "What points about this business process do I need to make sure everyone really agrees about?")
- Are the statements I've written testable?
(I originally wrote this blog post in 2012, and it seems like it has held up well over time.)
One great thing I’ve learned from Scala and functional programming over the last few months is this:
Make your variables immutable, unless there’s a good reason not to.
“Immutable” means that you can’t change (mutate) your variables; you mark them as final in Java, or use the val keyword in Scala. More important than you not changing your variables is that other programmers can’t change your variables, and you can’t change theirs.
Note: This is a post from 2007 that I just updated a little bit because I think there’s still some value in it.
A lot of people have written to say that it’s unfair that I think developers should never say “I’m 75% done,” or “I’m 90% done.”
So, to explain myself, here’s why I think you should never use a phrase like that:
As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:
Is this software requirement testable?
I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.
“Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.”
~ Steve McConnell, author of several famous programming books, including Code Complete
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 20.4, “Scala best practice: Use match expressions and pattern matching.”Back to top
Match expressions (and pattern matching) are a major feature of the Scala programming language, and you want to see examples of the many ways to use them.Back to top
Match expressions (match/case statements) and pattern matching are a major feature of the Scala language. If you’re coming to Scala from Java, the most obvious uses are:Back to top
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 20.3, “Scala best practice: Think "Expression-Oriented Programming".”
You’re used to writing statements in another programming language, and want to learn how to write expressions in Scala, and the benefits of the Expression-Oriented Programming (EOP) philosophy.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 20.2, “Scala programming best practice: Prefer immutable variables (values).”Back to top
You want to reduce the use of mutable objects and data structures in your code.Back to top
Begin with this simple philosophy, stated in the book, Programming in Scala:
Back to top
vals, immutable objects, and methods without side effects. Reach for them first.”
This is an excerpt from the Scala Cookbook (partially re-worded for the internet). This is Recipe 10.8, “Make the Scala ArrayBuffer Class Your ‘Go To’ Mutable Indexed Sequence”
You want to use a general-purpose, mutable indexed sequence in your Scala applications.
This is an excerpt from the Scala Cookbook. This is Recipe 10.7, “Make the Vector Class Your ‘Go To’ Immutable Sequence.”
You want a fast, general-purpose, immutable, sequential collection type for your Scala applications.
Vector class was introduced in Scala 2.8 and is now considered to be the “go to,” general-purpose immutable sequential data structure.