Working with the end in mind is a habit made famous by Steven Covey‘s 7 Habits of Effective People. This principle states that you first need to have the end goal defined, then you build up steps to get to that end from where you are. Developers need to keep this principle in mind when writing software. It is a defined practice having the end state in mind with getting features done, but this end is just enough to get it done. Developers rely on other teams to deal with the deployment, testing, service requests, etc., leading to a mindset of not my job. The attitude that it is not my job or someone else will take care of it leads to people cursing your name and users leaving your product. So how can you prevent masses rising and seeking to plot your doom? Consider the following areas when developing your next feature; development, testing, deployment, maintenance, new features, and finally users using the system.
Using the Software
You may ask how does the implementation of a feature affect users; it is how they use it. The way you implement a feature may make logical sense to you, but it may not be the best way for a user to use it efficiently. Features are often not used how we envision them, and due to this gap, we get frustrated users, too much frustration, and we lose that person. So before we write the first line of code, we need to view our system through the user’s eyes and see how they will use it. After we have come up with a possibility that will work for our understood persona type, we can start building that feature. We won’t get this correct the first time around, so we need to make sure that the feature design is flexible to handle changes that will need to be made to fit our user’s feedback.
Maintenance/Monitoring
Our users have our new feature so how do we get feedback on how it is performing? Instrumentation. During feature development, we need to find where the best points are to add logging so we can have enough detail to fix an error as well know when our feature is getting a significant amount of utilization so we can increase scale. Without this information, it is virtually impossible to find and fix issues and allow for a system to grow.
Deployment
What libraries, services, and platforms can our system operate? Our friends in IT and operations spend time trying to figure out the answers to these questions each time release our software. To do this, they install the feature and try to use it, when errors occur then development gets a bug saying their system does not work. Often the resolution of the issue is, do you have x installed, or what is the version of the database server you are running? All while IT is trying to figure out how to get your system in place; your competition is releasing a similar feature. How much time wasted when you can supply a list of the services, and libraries you used to develop the system, and go one step further and test that it runs on another machine other than yours.
Testing
Review the changes made and validate the changes have not broken any unit tests, and for any broken tests fixing them. Resolving the unit test does not mean comment out the assertion, so it does not fail, it means learning why it is failing and addressing the cause.
Provide an excerpt for how the feature is expected to work that is clear for testers to read and build/update their test cases. We are not talking about war and peace here, but just enough detail that clearly explains the basics of what system(s) the feature effects and uses as well the expected states for the feature to work as expected. By doing this use cases can be thought of by the developer and fixed before handing off the code to be tested.
Development
Now we have thought about how our feature. Who will use it, who will be involved with its success, how we can be sure it will be the best version and quickly adapt to the demands made upon it. We now have an end and define the steps to get to that end. So now we can start to write our feature and be successful, right?
The answer is, mostly. There is one step that does tend to get overlooked during, and that is the maintenance of the code. After we have written our feature, we need to leave the system in a state where we can easily and quickly make updates to it, by someone other than ourselves. One such way is to follow patterns and practices defined in Clean Code, where the code produced is in small units that can be tested quickly, read and understand its intent as well composable so we have less to maintain not more.
Conclusion
These are just a few benefits gained when having the end in mind beyond the just getting the feature done and should be in the minds of each developer. True it does take more thought and time, but this little extra time, in the beginning, is time well spent when you want to focus on new features and less time fixing bugs.
