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.

Web fame is a strange thing

Web Fame

Web fame is a strange thing. Take Perez Hilton, who for years made a living from shock.  Now more contrite (i.e. maturer), he assumes we are all still interested in his transformations.  What he is is a tabloid titbit, peddling tabloid titbits himself.  Hardly Nobel prize material.  The web is still very two-dimensional, and therefore disposable.  The only way for people who are famous on the web to continue being famous the next week, is to do something else to keep them famous. Fame on the web is incredibly fragile – it is easy to get noticed for a short timespan – just do something degrading that goes against your moral fibre.  Offence is an easy way to get attention. And a lot easier with the amoral web.  Just shout and run away.

What strikes me most about web fame is how difficult it is to sustain – it is understandable that comparisons with Andy Warhol famous statement that everyone would be famous for ten minutes. For your average Joe, that is probably about all we can expect. Do we need it? Probably not.  But the negative effects can be huge, not least the anti-climax of your fame disappearing as quickly as it arrived.  Or even  worse, the backlash.  There are those who will revel in any kind of notoriety, even if teetering dangerously on the edge of morality.

It is less about the web itself, but more to do with fact it provides a platform for this to happen.  Something that was never envisaged in the early days of the Internet.  With availability of new technology, comes with it many surprises and applications that could have never been predicted at inception point.   If you consider of the influence of television and telecommunications, it is not that surprising to have a huge  evolutionary move forward on the back of it.  It is how we evolve in any event.

As well as the fame-hungry, there are the more aware that use this “web fame” to promote and market something or someone.  It may be a product or even a cause.  Now that is smart.  It is an interesting application of the same concept – to grab our attention, using diverse means, sometimes completely unrelated to what it is trying to promote.  Grabbing attention is the first thing to do, if you are trying to sell something to someone.

How many ways can you code

lean kanban

Not surprising our leaning towards manufacturing, given the budget production line obsession of business towards development.

The recent story on the cheapest meal, put me in mind of some dole/student classics. Poor mans pizza was rice and ketchup. Anything new can taste interesting, as with the toast sandwich. But you will find after 2/3 experiences, that culinary surprise will dissipate into reality of cheap vinegary tomato flavoured starchy rice. Adding tuna will allay that feeling for a few more meals but ultimately you have to spend more and more to get it to taste nicer. By which point, you may as well have gone for making a decent budget casserole or lasagne.

Basically, you can go too cheap. And many saw Agile as a way to do it on the cheap – why? Because the traditional structure of a project was changed, with generally less roles which immediately followed was less people.  First error – assume downsizing was part of Agile solutions!  They don;t need repeating, but the 4 core statement in the Agile manifesto were:-

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Of the four core Agile Manifesto directive, the overall experience for myself was that: (1) was done the wrong way round, (2) highlighted development wasn’t that agile, (3) companies couldn’t separate the two and (4) led weak/poor project management.  My favourite of the principles regards development was: Continuous attention to technical excellence and good design enhances agility.   For myself, Agile was about doing things better, not doing things cheaper.

With Lean, there isn’t so much room for subterfuge or being dogmatic.  A startup illustrates to benefits of Lean (and Kanban), as it is more given to dynamic decision-making and calculated risks. Whereas Agile collated principles from existing, though disparate, methodologies; Lean has far more focused sense of continium and improvement – not principles for development but any kind of engineering, where the process to produce a product is just as important as the product.  To manage such a demanding development flow, Kanban provides ideal based to manage a project.  The “Work in Progress” principle behind Kanban, illustrates acknowledgement how rapidly things can change, and the balance work evenly and maintain a realistic map of progress.

Lean and Kanban are deceptively simple, because of course as we all know, management is by far the riskier element on modern web projects.  It takes skill and ability to think on your feet.  Some of us actually enjoy that!