Software developers like to write code. Well that makes sense but software development is the process of delivering working code to an environment where it provides value to a user. In my experience, a developer will generally spend their time doing the following tasks:
In Scrum (and other time-boxed methods) a commitment is made at the start of the sprint to complete a certain amount of work. This approach encourages on-time delivery of features, a team only commits to what it thinks it can do based on previous iterations and it makes sure this is delivered. If things got a bit close towards the end then in the next sprint they should commit to a bit less and visa versa. This seems like a noble and pragmatic approach at first however there are some flaws, mostly due to human nature.
I’ve put in quite a lot of effort learning about automated testing in the last few years and have become quite passionate (some may say opinionated) about the subject. Through trial and error, reading and working with some experienced QAs, I’ve formed some rules for myself about how I write BDD style tests. I’d like to share one of these as I can’t find anything on the internet that suggests or explains it. The rule is:
In my continuous quest to learn how to develop better software I’ve been reading a lot of articles warning us of the risks of ‘using Agile’. Often these articles or their comments have something along the lines of, “there are 3 types of developers, the bright ones, the normal ones and the stupid ones. The bright ones will make any methodology work and the stupid ones will make any methodology fail so we have to look out for ‘normal’ developers…”. Every time I read this it frustrates and annoys me so I thought I’d make my feelings public in the hope that someone will benefit from my opinion.