developer (20)

It’s not like the good old QA days …

I am starting to think those of us who grumble about misuse of term “QA” (Quality Assurance) are maybe in the realms of grumpy old men/women. I now beginning to realise that yes, people use the term far too loosely without thinking it through. But more is expected of the tester these days, than simply testing – and those expectation do fall within the realm of Quality Assurance. Quality Assurance and Testing used to be distinct areas, though testing came under the overall remit of a QA manager, as it’s a quality gateway task.

The modern tester

I choose to healthily ignore the various various debates around the place of the tester, as it hasn’t changed that much. With every wave of new developers, comes along the same misplaced arrogance that they can do no wrong.  The chips have yet to leave the shoulders.  

End-users as security testers

Increasingly security testing of web applications are left to the end-user to discover. The web is generally seen as an imperfect thing, so it is not surprising that most users do not expect a website that works well 100%. What I have seen on the best Agile and Lean projects, is this is omitted to much further down the cycle, if at all – but why? Yes, they are skilled testing areas (and hence higher cost to secure fully skilled resource), but there is a lot that can be done, with the right tools and approach.

Testing is still alive and always will be

As usual, the swing against testers has gone way too far (again). More technically competent, sure – but advertising for testers, focusing on programming ability alone will get you another developer. And maybe someone who neither a good tester or good developer.

I am quoting myself from a linkedin update, but what the hell – after 17 years in QA, I think my views must be valid enough to quote. 

Refucturing with MDD

Refuctoring is the process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anybody except yourself. Comprehensive regression testing guarantees that nobody will be any the wiser.
Jason Gorman

Both “Refucturing” is term coined by Jason Gorman, and illustrate a fundamental problem with these newer approaches to develop, that demand transparency in coding process. I guess I always knew people generally tried to make themselves invaluable to keep their jobs and professional stature.  Sometimes these efforts would benefit the company, but mostly not.  While we all appreciate the ethics behind Agile, Scrum and the like, it is difficult to marry it up with working culture, which is still largely a power and longevity struggle.  It wasn’t development that had to “go Agile”, it was the workers.  That was largely what the Agile manifesto was aimed at people.

For myself, the dawning of realisation was a slow one, but had be accumulating for many years.  I have no idea of working in MDD fashion, as I have never had a mortgage or been inclined to perpetuate a job by self-motivated means. It was when I started working on BDD projects that the MDD principle became apparent.  These BDD project were web application re-factoring projects, which illustrated how unpredictable these projects can be.  BDD demonstrates how to reign in this unpredictability by using a strict requirement-to-code process, that is (theoretically) all level of user contributing – from tester to stakeholder.  And they are some good tools to help with this.

The underestimation of complexity of tools like Cucumber and Specflow has meant BDD has travelled a rocky path. Not at least, as astutely pointed out by, MDD can drive developers in their careers and behaviour in the workplace. i.e. job protection. Any ideas that even vaguely touts the idea of “anyone can code” puts the fear into many a developer.  Hence the distinctly old fashioned behaviour remains, to make the developer more irreplaceable by making it difficult for others to understand or modify their code.  This is part of the reasons testers can be irrationally resented, as it is this group that threatens the MDD developers.  In testing, we are not interested in mysteries, we want answers.  And if in the course of testing, it appears that same or similar problems occur again and again, then it is indicative of fault in development process.  In the course of this, code has to be reviewed and if necessary refactored.  So the hard MDD work is removed to present a more transparent view of the code.


Re-factoring projects are feared ground for MDD-oriented developers.  A bit like the 70’s ad for the amber gambler – “dont be an amber gamber – you may not be the only one around”.  In fact, you can see them approach meltdown.  Being a flamboyant individualist coder has little value, as with dependency on individuals brings increased costs.   The MDD developer is very mistaken, as a developers who codes well and to standards, and is transparent in his/her work, is invaluable resource.

The Mortgage-driven Development Manifesto

  • Timesheets and invoices over principles and ethics
  • Unmaintainable software over clean code
  • Contract renegotiation over a barrel
  • Unlimited overtime over a sustainable pace
  • Contracts that fall outside of IR35 over and over again

Until the way we work is address, there will always be MD-style problems.  I have no such mortgage concerns, and have no fear of not knowing the future, but I know majority require some kind of security.  The fundamental problem is people’s motivations at work are largely self-oriented.