By: Jonathan Donkin
This is the 2nd part of a 7-part series. The first part can be found here http://stgconsulting.com/habits-of-highly-effective-software-developers/. As always, I look forward to your thoughts.
Begin with the End in Mind
In the Seven Habits of Highly Effective People, Covey makes the point that this habit is about leadership and your circle of influence. Covey makes the analogy of a team slogging through the jungle and how management is happy with how much jungle has been cut away by the workers, but the leader is in the tops of the trees asking the question “are we going the right direction?”.
As we build our products we should be asking ourselves “are we going the right direction?”. This simple question can be applied to everything from the architecture, framework being used, and even the individuals’ efforts on the story they are currently working on.
It is my experience that when you start working on a story while following the Agile methodology, it helps to know where you are going and what you are delivering. While this seems to be intuitive for those that have only worked on well flushed out user stories, I have definitely worked on stories that weren’t well flushed out for some reason or weren’t technically reviewed properly. When this happens, time is wasted going back and forth, either to figure out the how or the what of the story. If we begin a user story with the end in mind, then the process becomes much smoother in the long run, and it is easier to deliver what is being asked for by the user.
This starts by getting all of the users’ requirements upfront and then asking the question of what is being delivered. In the what, we should also be looking for any gaps in the requirements such as what is the expected behavior if this form field is not filled out and the submit button is clicked. As those requirements, and with it understanding, is figured out then we begin to focus on the how. How are we going to write this so that the requirements are met? I also think about how I can write the code in a way that it is clean (if you aren’t familiar with what is clean code I highly recommend that you read Clean Code by Robert Martin) and loosely coupled (think SOLID principles).
This is where the architecture of our code definitely comes into play. Do we introduce an interface to create a contract between one class and another? I say yes and with this as well as other parts of the SOLID methodology we begin to create decoupled and clean code. Another aspect of SOLID that makes a huge difference in the readability and maintainability of our code is keeping methods/functions small and only doing one thing (Single Responsibility). This all helps with loosely coupled code which makes it easier to maintain and change this code in the future as our user requirements will always inevitably change. So, by following these kinds of principles even if we don’t know what the end is with our project we are still keeping the “End in Mind” by allowing the code to “easily” change as needed.