The number one worst practice I see consistently in object-oriented software development is writing procedural code. Even object-oriented programming projects contain code that is highly procedural. You’ve probably seen code like this yourself where it’s basically a series of steps that prescriptively describe a process that is then wrapped within a class.
This is really not taking advantage of OO and it has some serious consequences for maintainability. Object-oriented languages gave us the capability of doing better but I rarely see developers take advantage of using objects. Encapsulation is useful and important and most of us understand the notion of hiding data through access modifiers or hiding behavior through interfaces but there are subtler parts of the object paradigm that tends to escape many of us.
I call it a paradigm because it really is a different way of thinking and not just a new set of keywords. When we model problems that reflect the domain that we’re working in rather than reflecting implementation details that are part of the way a computer processes information, we can take better advantage of the tools in object-oriented languages and write more extensible code.
I don’t do use case modeling when I’m doing object-oriented programming. While use cases are appropriate for many kinds of programs or processes, they are not appropriate for doing true object modeling. Use cases define tasks as a series of steps, which translates into procedural code. For this reason, I focus particular attention on the “so that” clause of user stories instead.
You will recall that a user story is typically made up of three pieces: the role, the desire, and the so that clause. For example: “As a job seeker, I want to search for matching positions in my area so that I can find potential employers.”
This is the full extent of the user story, but it doesn’t mean I can code with only this information. We refer to user stories as the ‘promise of a conversation.’ The conversation is between the developer and the user, or user representative—our Product Owner.
Notice all the context that comes with a user story. The user states who they are, what they want, and why they want it. This context helps us, as developers, stay focused as we discuss the story with the user. Now I can have a meaningful conversation about the best ways of allowing a job seeker to find potential jobs, and I have a whole raft of questions to ask such as how we define “in my area” or what “matching positions” really means. These things are best left to a conversation because each feature has so many details that writing them down in a long-winded specification can easily devolve into mind-numbing drudgery.
I spent more than half of my life as a developer, including many years where I was managing other developers, and the sad truth is that far too often we simply don’t read specifications. We’d much rather just write code, so having a story for a feature that is only a sentence long gives us a higher probability that the developer will actually read it.
But far more important is that we engage users in the process of finding the best way to do what they want. We think we’re being hired to build a software system but that’s only part of the story. We’re really being hired to understand our customers’ business, or whatever it is we’re writing a program about, and then we memorialize that understanding in code.
Software development is a discovery process, and this is as true for our customers as it is for us. By engaging our customers in the process, we can get the best of their attention because as much as we hate having to figure things out upfront, they probably hate it more and have far less experience doing it. As we start to engage with our users, we gain new insights and so do they. That helps us build a better system for everyone.
Previous Post: « How Small should a Story Be?
Next Post: How I Use User Stories »