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.