So easy a monkey could do it!
As Developers, we have all had to complete some really difficult and sometimes esoteric tasks. You know the type…a Business Requirement that requires a 17-step process to enter an order only on the first day of summer solstice during a leap year and it had to be a full moon. Some requirements have been so utterly soul crushing that the sound of hope dying could be heard from one of my fellow developers. Yikes!
Now that I’ve managed to depress and send you spiralling into an Apocalypse Now-esque Vietnam flashback, I would like to say that I think it’s our fault that we feel that way. Is it that we are afraid of the big, hairy challenges? No. I believe it’s obvious. It’s the edge-cases. The hard-to-track bugs that these solutions can produce. Most Developers can solve some very complex tasks. Fewer, but still many, can solve complex problems in an elegant fashion. It’s the even more obscure bugs that arise from a complex requirement. We fear and loathe these assignments because what we really hate is messing up and we mess up not in the original implementation of our solution but the bugs that follow.
The point that I’m very slowly making is that we as Developers are very poor at a couple of things. Although I think on the whole, things are getting better, nonetheless there is room for improvement. The first problem is that of a strong ethic for Unit Testing. I think people like Robert C. Martin (Uncle Bob) have made great progress in bringing awareness and some much needed practicality to this area, I still feel like there’s a stigma towards it. An example being a talk that I attended which was delivered by Curtis McHale about Unit Testing in WordPress. I happened to overhear a couple of Project Managers dismiss the information and advice in his talk saying: “Too bad there’s not enough room in the budget for that…”. In my humble experience which is relevant to this topic, YOU ALWAYS PAY FOR LACK OF TESTING! Whether you budget time for it or not. Again, you always run into the scenario that I outlined in the beginning of this post. Requirements change, they become more complex and you start introducing more bugs from producing more complex solutions. Something I strive for in Development is that I believe we should try to follow the Lego model as closely as possible. That is, Lego are individually very simplistic. However, what you can build from Lego is awe-inspiring. When we treat our functions and methods like Lego, we are making them simplistic, but highly testable. When we have such complete and utter confidence in these atomic parts of our code we can stack these very simple parts in marvellous ways. Sure, we will still have errors and bugs but with a solid foundation of tests to rely on, we can fix these with a high degree of confidence that we will not introduce new issues.
The second problem is that I feel that we are poor at automating our work. Don’t get me wrong, I’m not aspiring to having everything done in some Dreamweaver-like way whereby bland, cookie cutter work is spat out of some script. I believe there is a natural symbiosis of code and coder that can be achieved by automation. I feel that in the past few years, we as a community have become more proficient with this. Examples of tools that enable automation of our work would be PhantomJS or Yeoman, or the WordPress Command-line Interface. In my opinion, a Developer is a bridge between the Computer and the Stakeholder. Duh, right? But to delve deeper into this, Developers are intelligent and possess a vast array of skills which include being able to listen and communicate and also to be able to implement solutions to problems ascertained from the former skills. How many times have we futzed around with some configuration settings for a Web Server to deploy a site on or setup a Web App with a Login page and User Account Management? Although we come up against really tough, Business problems that we have to solve, I feel like I still see a lot of Developers doing stuff “by hand”. I think this feeds into our fears in regards to the code we write. So we code up the solution and then we test it, doing the same loop through the Code-Browser Refresh cycle. This is silly and presents way too much opportunity for Human error to slip in and mess things up. Let the computer do the grunt work. Again, this has improved in the past couple of years, but I feel that as Developers, we really need to form better habits around this and push this to the Business and Management side as something we need to spend time on which will pay dividends down the road.
I will close this ~900 word post with two challenges. Challenges that I have taken on myself. The first being to write at least one extra test per day to increase code coverage and the second is to automate at least one repetitive task that you perform in your day-to-day work. Our goal should be to make testing our work so easy a monkey could do it.
