Tag Archives: agile

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!

R & D

research and development

Research and development – less of a specialised area, more normality.  Of course there is a lot of “keeping up with the Jones’s” marketing around a lot of newer technologies and techniques emerging. You can end up like a pinball, bouncing between different things, that are actually the same. If you alter the way to see coding, it can help.  A lot of the practices advocated in Agile and others, is Iterative and Incremental, i.e. the practice of shorter release cycles, and incremental releases within those cycles.  The ultimate aim is to produce a continuum of development, integration tested at source.  At at the end of each short release, the software should be demonstrable.

To achieve this not only takes applied effort to make the process work, but flexibility and adaptability. These are not two fashion words, they are important in Iterative and Incremental development, enforced with a Thor hammer with Lean development.  The Incremental part demands effective Continuous Integration, i.e.  the regular (usually daily) check-in of all code work and a set of automated tests run (usually overnight).  It leads to a better ongoing development and testing process, that can be sustained.  And avoid pointless stress. Burning out project team members is still ridiculously common, and it is not wonder developers and testers lean more to contracting.

In a truly communicative team, it is surprisingly how many changes can be made mid-stream.  In fact, if this voicing-up is encouraged, you can prevent things slipping further down a bad path.  If that isn’t encouraged  or an atmosphere of blame-culture exists, you are stuffed because problems can slip far down the line, to give you a step-down type bite on the behind.  There was a reason step-down approach to development is costly on modern IT projects.  There was an area of risk that never could be accounted for, until point of testing.  And even then, a more obscure issue could pop up on live system.

This is really to hammer home the reduction of risk, when adopting an R&D approach to development. It takes effective management and someone who has acute gift for time and resource management.  R&D doesn’t have to be limited to development, testers have long been using the open source world, or even their own programming skills, to assist the QA effort.  Sometimes a requirement only becomes apparent once a project is in movement. A project can learn from others of course, but will also have it’s own demands.

The best way to spread knowledge across multiple projects is not weekly meetings in the canteen or Starbucks. It is sharing resources around effectively (this is where Kanban can help). You don’t have to latch onto a methodology or set your store in clunky all-in-one “Agile” software. But taking ones more specific to your needs is a sensible approach.  You don’t find the methodology, it finds you – so to speak. And commit to the damn thing – I have seen so much weak Scrum-mastering over the last decade, it almost makes me weep for the fine methodology it is.  But even that approach seems slow now – the march of time!

Whilst it’s important to keep up with the IT world, its also important not to become a slave to it.  Development is evolving in great directions – more programming language agnostic directions, to help bridge gaps between requirements and code.  Testers are required to program these days, whether Selenium scripting or being able to debug code.  There is no escaping developers and testers have to adapt faster now, and project management even more so. Its a good time to dump the labels, and get to the core of a project which is the management of development. You can argue that R&D is a fashion label, and you are probably right.  Maybe it’s is better to say it’s right, if you have justification to use it – not just using the word!

Change please …

new monkey

Following reading Elisabeth Hendrickson’s post about disillusionment with with QA. There is too much resistance to the big change that is already upon us in QA, but so many in denial. We all need to code.

I saw a similar turn in 2000, when the sudden more technical and adaptable demands on a tester increased. A wave of testers left the profession, and and then suddenly flooded with well-meaning amateurs. I feel lucky in that my path started down the new route early. Sure, it was messy and chaotic time – like babies really, muddling through radical change to web projects. Faster to live, cheaper but not necessarily the attention to quality that Agile and other modern approaches promoted. Anyway, that is certainly water under the bridge now. For years I have been using different tools for automation, dependant very much on client resources and budget. I was in a nice niche of free-thinking digital media and creative industries, where change and improvement are seen as the norm, not the exception.

I feel a little confused, but not enough to concern me. At this time, it is very important to choose a good direction. Sure, I could cruise on one path pretty much to retirement age. Well, that isn’t going to happen. It’s a calm before the storm at the moment – everything is already in place, but there is a resistance from many to the changes happening. There has to be more assertive efforts to follow the approaches. Lofty concepts such as Lean development is a tall order for a company struggling to maintain just Scrum. You need expertise to drive it forward, and simply change people’s job titles just simply isn’t enough.

So we all need to change, not just us in QA. Rather than the mass production approach endemic in software development (little wonder we gravitated to manufacturing processes for inspiration), quality needs to be more in focus. And building good teams – we are dealing with human being ultimately.  After all, we are supposed to be embracing change, not fighting it 🙂

Plugins for testing WordPress

AntiVirus for WordPress

Viruses, worms and malware exist for WordPress and could easily attack your WordPress installation. AntiVirus for WordPress monitors malicious injections and warns you of any possible attacks. With multilingual support.

Better WP Security

Takes the best WordPress security features and techniques and combines them in a single plugin thereby ensuring that as many security holes as possible are patched without having to worry about conflicting features or the possibility of missing anything on your site. With one-click activation for most features as well as advanced features for experienced users Better WP Security can help protect any site.

SES Theme Split Test

This plugin lets you set up two different templates with differences that you think might increase conversions, serve these different templates up to users, and track their activity using custom segments in Google Analytics. Alternatively you can use it to “choose” a particular theme by setting a URL parameter so you can experiment using different themes yourself

PHP Validator Lite

PHP Validator is a developer tool. It scans the file you specify and determines whether you have undefined functions or methods.

ThemeCheck

The theme check plugin is an easy way to test your theme and make sure it’s up to spec with the latest theme review standards. With it, you can run all the same automated testing tools on your theme that WordPress.org uses for theme submissions.

Plugin-Check

Plugin-Check runs most of the checks that Theme-Check uses against all your plugins

Monster Widget

Provides a quick and easy method of adding all core widgets to a sidebar for testing purposes.

Debogger

Debugging tool for theme authors and reviewers. This tool intercepts all debug information and prints it all out neatly into the footer. It also checks each page for W3C validation. This plugin is released as a tool to aid the development of themes and plugins for WordPress and can be used to aid debugging your theme before submission to the themes directory.

Debug Bar

Adds a debug menu to the admin bar that shows query, cache, and other helpful debugging information.  Many extensions to increase features.

Regenerate Thumbnails

Regenerate Thumbnails allows you to regenerate the thumbnails for your image attachments. This is very handy if you’ve changed any of your thumbnail dimensions (via Settings -> Media) after previously uploading images or have changed to a theme with different featured post image dimensions. You can either regenerate the thumbnails for all image uploads, individual image uploads, or specific multiple image uploads.

Log Deprecated Notices

This plugin logs the usage of deprecated files, functions, and function arguments. It identifies where the deprecated functionality is being used and offers the alternative if available.

SimpleTest

SimpleTest for WordPress is a tool for WordPress plugin developers who want to create and run automated tests for their plugins. It includes SimpleTest 1.0.1 and uses a shortcode to let you run unit tests on WordPress plugins, and see the results in a WordPress page. Since it runs within WordPress, you can also do integration testing of plugins (that is, custom WordPress functions used in the plugins will work correctly when the tests are run).
Requires the plugin below to be installed first

Toppa Plugins Libraries for WordPress

Facilitates the use of Agile coding techniques in developing WordPress plugins.