I have been a software developer by trade for over a decade. I have made my name and living by writing software that is functional. It even sometimes satisfies the business requirements. I cannot count the number of times when I tell myself, “who the F is going to use this software?”.

Let’s be honest software developers out there; We do not really think about the “real” users that would use our software! We write software in line with the business requirements written by people trying to paraphrase what the “real” users want. And most of the time, they too do not really think about what these users really want.

What we are so accustomed to doing is what is known as an acceptable way to fail. We write software given what the specs say. We rarely talk to the real users, we barely even try to be in the same shoes as the users when we write our software. We just make it functional.

Now, is this a bad thing? Can’t we just blame it on the lazy or incompetent business analyst who didn’t think it through before penning the business requirements. Can’t we just say that this is how software was made before and that’s how were going to do it today? NO! Well, actually, yes. We can blame it all on the output of the process before implementation because we can always rely on QA to make sure everything would be usable in the end. But is this an acceptable way to fail?

Ideally, everyone on the development cycle should do their part and make the software better as it goes thru the cycle. Better requirements means better design means better software which then leads to testing more relevant parts of the software. See what happened there? Everything better eventually leads to more relevant testing. I find it odd that only when everything else is better, does testing actually become valuable!

Everything better eventually leads to more relevant testing

Mad Computer Scientist

Let’s look at it from a negative perspective. Bad requirements means horrible design which leads to poor development and ends with futile testing. QA ends up testing whether the application won’t crash when you start it! I know its an important test, but when testing a piece of software that has so many defects, you end up being paranoid and test every single tiny thing that is actually insignificant in most cases. That time could have been better spent testing whether the software won’t automatically fire a missile or if the software is aesthetically pleasing to the user.

Bad requirements means horrible design which leads to poor development and ends with futile testing

Mad Computer Scientist

To all the QAs out there, my heart goes out to you. On behalf of my developer brethren, I apologize for writing horrible software and putting this burden upon your people. I pledge to write better software by making sure that what I write is relevant and actually useful. But if I get bad requirements…