WordPress founder Matt Mullenwegs blogged about this addition and WordPress supports embedded tweets on its hosted blogs in a couple of ways. The Twitter Blackbird Pie or the Twitter Embed shortcode

As this is a standalone WordPress blog I had two options:

• Use the Twitter Blackbird Pie Plugin
• Embed Tweets using the Twitter generated HTML

So without further ado, here are the two options in action:

Twitter Blackbird Pie Plugin

Just applied a new Twitter theme called "Sandy Shore" to my profile, take a look! Got it from http://t.co/GEZnqiGb

December 23, 2011 3:16 pm via Tweety Got BackReplyRetweetFavorite

@PeterSellars

Peter Sellars

Twitter generated HTML

Just applied a new Twitter theme called “Sandy Shore” to my profile, take a look! Got it from TweetyGotBack.com

— Peter Sellars (@PeterSellars) December 23, 2011

I feel the Twitter generated HTML currently meets my expectations better than the Twitter Blackbird Pie Plugin.

The Twitter Blackbird Pie Plugin does not have a ‘follow’ button and has inserted the shortened url rather than the link alias. I would also like some of the capabilities offered by WordPress’ shortcode options included in the Plugin. I shall have to do a bit more digging I think!

Day 1 of the YOW! 2011 Brisbane Conference was full of fantastic talks, book recommendations and great giveaways as usual. As well as the YOW! 2011 Conference t-shirt I picked up an Atlassian t-shirt and enjoyed some micro dots for afternoon tea thanks to ThoughtWorks.

I had been really looking forward to the DevOps stream in the morning featuring Jez Humble of Continuous Delivery fame and ‘The Build Doctor’ himself Julian Simpson and had an enjoyable morning session. After lunch things begun to hit another level with two presentations by Joshua Kerievsky author of Refactoring To Patterns on Lean Startup and The Limited Red Society. I also enjoyed learning about QuickCheck testing capabilities from John Hughes, and Haskell from one of its founding fathers Simon Peyton-Jones. The JVM keynote from Oracle Vice President of Development Camron Purdy, which opened the conference, was interesting but not really worthy of its keynote status. I also failed to heed the lessons of conference pasts and went to another labourious IBM SOA presentation this time provide by Rachel Reinitz.

In this blog entry I will provide a brief synopsis of each of the sessions I attended. Comprehensive notes and details of the presentations I attended will hopefully follow over the coming weeks.

Top 10 JVM Erroneous Errors – Cameron Purdy

Cameron Purdy, Vice President of Development at Oracle started the conference off presenting his list of 10 JVM issues he would like to see addressed. His top 10 list ended up actually being 15 though as he continued to rattle off the issues after presenting his top 10! He got plenty of traction from past Java design decisions limiting its ability to adapt to modern developer whims.

The Java Virtual Machine Specification

He stated his opinion that Sun had not done as good a job of Java as he thought the case should be, imploring that Oracle would endevaour to do a better job. He presented his list with some humour but seemed to be met with mixed emotions from the crowd. The overall feel from the talk was that Java needed to become more dynamic, along the lines of Groovy and other current popular dynamic languages if it was to meet changing development needs.

Personally I found it quite interesting and although I will take interested looks in the direction Oracle takes Java and the JVM and how/when Cameron’s list is addressed by the team – I myself will be utilising Groovy to have access to the capabilities now.

Download Presentation Slides

Continuous Delivery – Jez Humble and Martin Fowler

Continuous Delivery Book @Amazon

Having read and digested all the information in Continuous Delivery already I was expecting big things from this presentation. The loud mouth of Software Development Martin Fowler lived up to his billing with a fantastic bellow towering over poor Jez half way through representation. In truth I was a little dissapointed with the content – having read the book I wanted the ‘extra mile’ but the talk was aimed more at those who had not yet read the highly recommended book.

The talk outlined Continuous Delivery experiences and real-world examples of successful implementations, including the obligatory reference to Flickr whenever this topic is discussed. The main body of the presentation revolved around the observation that frequent delivery reduces risk rather than increasing it and that metrics provided by fast feedback are vital to succesful Continuous Delivery. It also aimed to debunk the myth that Continuous Delivery can’t work in Enterprise deployments.

Overall it was a good introduction to the topic (which no doubt was expanded on in the workshop scheduled later in the conference), providing an outline of practices that contribute to Continuous Delivery such as deployment pipelines, automation etc, but left me wanting more. If you had already read the book the presentation had little new to offer.

Download Presentation Slides

We’re All Developers Now – Adventures in Infrastructure as Code – Julian Simpson

Unfortunaly for Julian this presentation was beset by technical issues from the start and I felt it affected his performance and the session never lived up to expectations for me. At one point Julian ran a demonstration which seemed painfully slow and was compounded by the fact it was a video from a live session using the venues really poor wifi!

The crux of the presentation was really a comparison of Puppet and Chef, two competing configuration management tools. Julian discussed why these tools are useful before proceeding to detail the differences between them from an implementation viewpoint. He also spent time discussing the need for collaboration between developers and administrators in the DevOps movement.

The Build Doctor - Julian Simpson

Overall I felt the presentation showed the differences between the two tools nicely and was a good introduction to their capabilities. Once again though I felt this introductory nature left me wanting more. I was hoping to hear more about server farm updating and management capabilites with examples and stories from the trenches.

Download Presentation Slides

Lean Startup – Joshua Kerievsky

The Lean Startup - Eric Ries

This session was the stand out presentation of the conference for me, although some others didn’t seem to share my opinion – no surprise there considering the development focused audience. From a business/entrepreneureal viewpoint I like the principles and process behind Lean Startup. In this talk Joshua outlined differences between Lean Startup and Agile supported by some real-world implementation experience.

Joshua acknowledged Eric Ries and extracts from the The Lean Starup at several points in this talk, even though he tended to disagree and correct Ries views at times. His real focus was on the process Lean Startup utilises to see/eliminate waste in a capital efficient manner. The constant validation of hypothesis (scientific and measured goals) is at the centre of successful Lean Startup. The section on Customer Discovery resonated well with myself, and I have put some of it into practice already.

This presentation was presented in a really professional manner, in front of some legends of the Lean world (Mary and Tom Poppendieck) who appeared to endorse its content, which I think added to the validity of what Joshua had to say. It was great to hear about some real-world implementations of techniques discussed too. I tend to feel Lean and Agile are complimentary rather than competing techniques – although view both as labels for doing things more effectively!

Download Presentation Slides

The Limited Red Society – Joshua Kerievsky

This was another inspiring talk from Joshua. This time his focus was on how to keep your code out of the red, and thus in a releaseable state at all times. Through the use of baseball statistics Joshua introduced and highlighted the value of statistics and data visualization. He then went on to show how tools his team are working on can assist in providing statistics for developer sessions that aim to improve their capabilities to keep code in the green.

The Limited Red Society

Joshua challenged the audience to consider how we measure the value/productivty of code checked out and being worked on. He invited us to look inside this black box of development using a tool his team are working with. The tool provides information on code status and activities during a recorded session. At the end of the session a visualization helps to assess if the session was productive and can be reviewed to look at ways developers can become more effective. A very interesting insight into development practices.

Having heard that J.B. Rainsberger had learnt he probably refactors at the wrong time too often by using the tool, Joshua had some real clout to back up the tools intended value. With the goal being to keep your code is in a releasable state more of the time – a worthy goal in my opinion. I feel every developer should strive to become a member of The Limited Red Society.

Download Presentation Slides

SOA Connectivity and Integration…Real World Examples – Rachel Reinitz

Where should I start? I should have learnt my lesson from previous conferences and avoided the IBM SOA presentation at all costs! Something in my brain told me this would be different, it mentioned real world examples in the title for a start. I left the presentation reminding myself at any future conferences DO NOT attend an IBM SOA presentation.

IBM SOA - Gets The Red Card!!

There were real world examples discussed, cloaked in customer anonymity (what a surprise from IBM!). Often IBM were being portrayed as solutions saviours after smaller integration companies had apparently failed. Several references were made to teams that didn’t listen to IBM making mistakes in their solutions (reading between the lines – not implementing IBM software or heavy solutions as they should). It felt more and more like IBM beating up on the smaller players. More focus on how IBM overcame issues in ‘collaboration’ and learnt rather than dictated may have been more crowd friendly.

I was surprised that there were almost no tweets made about the presentation. Maybe those who enjoyed it were to afraid to say so and those who didn’t just could not be bothered to share their experience or were embarrassed to have been lured here in the first place! Little meaningful content, IBM are great, everyone else is doing it wrong delivered by an IBM zealot. Didn’t belong at such a great developer conference and got the red card from me.

Download Presentation Slides

Better Testing with Less Work: QuickCheck Testing in Practice – John Hughes

John Hughes - Energetic & Informative QuickCheck Presenter

John Hughes grabbed both myself and the audiences attention from the outset with his energetic and passionate presentation technique. His demonstration of array reversal was met with audible laughter in the room, such a simple, visual and energetic demonstration of concepts woke up the late-afternoon crowd. This was certainly a talk people enjoyed judging by feedback too.

John was here to pitch the use of QuickCheck for property-based testing in the development process. QuickCheck’s property-based testing may not seem intuative immediatly but with some practice it has real benefits. John demonstrated the QuickCheck capabilites that enable users to test more, with better tests and more tests than other libraries provide.

At its heart is the minimum failing case that QuickCheck reports when tests fail, without which the tool would be nothing more than a test generator – it is far more than that. John provided some real-world implementation examples and how QuickCheck even helped solve a complex Parallel Execution/Race Condition issue in a legacy codebase.

This was a well received presentation and there is no doubt QuickCheck is worthy of closer investigation. I would like to investigate the control of data used by the tool to create tests etc, and if the minimum failing test case meets my concerns over the failing of more than one test case based on a single property change. Also where does the tool fit in, should it be used to identify missing unit tests or as a replacement for them? Great tool though…off to investigate it now!

Download Presentation Slides

Escape from the Ivory Tower: The Haskell Journey From 1990 to 2011 – Simon Peyton Jones

This was a fabulous keynote presented with passion, enthusiasm and ultimate Geek appeal by Simon Peyton Jones. His energy, facial expressions, body language and amusing deliver had the majority of the audience captivated by this talk. Haskell may be the realm of functional programming devotees but this presentation appealed to the massed ranks of YOW! Brisbane.

Haskell - Think Like A Computer Scientist

Simon took the audience along on his Haskell journey from its founding principles, its principle driven evolution over the past 21 years, and its continued attempts to avoid success at all costs! With humours self-deprecation Simon showed how Haskell is ‘a language everyone talks about but no one uses..’ and outlined the languages key features, and how some design decisons have been reached and implemented as the language continues to evolve. He waxed lyrical about Monads & Type Classes as the foundation for Haskell usefulness.

A fabulous way to end the first day of YOW! Brisbane 2011 this was truly an inspiring story. Simon showed that with enough passion and faith in your principles whilst sticking to your guns you may just be able to infect others. We may not all jump in and start using Haskell, but there is no doubt understanding the ideas behind it could make us better programmers in whatever language we choose to use.

Download Presentation Slides

Overall day 1 got better as it progressed with a slight blip on the radar when I made the mistake of attending the IBM SOA talk. The two talks from Joshua Kerievsky were inspiring, John Huges was stimulating and energetic whilst Simon Peyton Jones provided great entertainment and plenty pf food for thought. I was definetly feeling invigorated and day 2 was eagerly anticipated.

Quite an old presentation, but does highlight why you may want to start considering Gradle as your next build tool. Take back control of your build and and model your automation domain better. Hans demonstrates some neat features such as finer forking control and parallel builds, as well as demonstrating a number of benefits gained by the declarative nature of Gradle builds – the use of describing the ‘what’ rather than the ‘how’ as he refers to it. It is slightly annoying when he talks and you can’t see the screen but you can get the gist of it.

JFrog Seminar – Gradle, Hans Dockter – HiRes from JFrog Ltd on Vimeo.

The YOW! 2011 Brisbane Conference starts today and I am lucky enough to be attending.

My plan over the next few days is to attend the following sessions and I will write up my notes over the next few days.

Monday 5th December
9.00-10.00 Top 10 JVM Erroneous Zones – Cameron Purdy
10.30-11.25 Continous Delivery – Jez Humble and Martin Fowler
11.30-12.30 We’re All Developers Now – Adventures in Infrastruture as Code – Julian Simpson
1.15-2.15 Lean Startup – Joshua Kerievsky
2.15-3.15 The Limited Red Society – Joshua Kerievsky
3.30-4.30 SOA Connectivity and Integration…Real World Examples – Rachel Reinitz
4.30-5.30 Better Testing with Less Work: QuickCheck Testing in Practice – John Hughes
6.15-7.30 Escape from the Ivory Tower: The Haskell Journey From 1990 to 2011 – Simon Peyton Jones

Tuesday 6th December
9.00-10.00 Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topographically Connected Quantum-Relavistic Parallel Timespaces…Made Easy! – Damian Conway
10.30-11.30 Problem-solving and Decision-making in Software Development – Linda Rising
11.30-12.30 Domain-Driven Design for RESTful Systems – Jim Webber
1.15-2.15 Product Engineering Innovation in Legacy Code – Dave Thomas
2.15-3.15 Three ‘Tall’ Tales – Kevin O’Neill
3.30-4.30 The Future is Parallel, and the Future of Parallel is Declarative – Simon Peyton Jones
4.30-5.30 Feedback Makes Everything Better: Understanding the Software Engineering Process – Bjorn Freeman-Benson

Evolution

Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?

This is a light hearted look, with some serious undertones, at the evolutionary state of Test Driven Developers. I hope you enjoy your journey of discovery…

Homo Habilis

Homo Habilis

Sitting at the bottom of the Test Driven Developer evolutionary tree this member of the species is not really a Test Driven Developer at all!

This member sees no need to write any tests, holding the belief that they write defect free code first time all the time. He makes extensive use of copy and paste techniques, deeply nested conditional statements and has no understanding of design patterns. They add to the technical debt of the project constantly as a result.

They can often be seen up to their necks in a debugging session trying to fix production issues. Issues introduced by other members of the species according to the Homo Habilis team member!

Some members of the tribe known as ‘management’ are impressed by this members code output blindly ignoring the number of defects and regression issues introduced by his work. They have been the cause of revenue losses totally millions of dollars. Far from being extinct, this species is a menace to the development society.

If you encounter one of his kind please remove their head from their ass and teach them to read before getting them to read this blog post ‘TDD for Dummies’

Neanderthal

Neanderthal

The lowest member of the evolutionary tree that attempts to writes tests.

They do not really understand why they are writing these tests and do not understand the benefits testing provides. They had seen a member of the Tester species write something called a test and due to their nature of imitation tried to do the same.

Their tests are written after the code and  follow only happy paths through the code (the Tester they had witnessed was low in the Tester species evolutionary tree).

This member copies others and has limited capacity for improvement. There poor development practices and inability to understand design patterns adds to project technical debt, even though some of the tests they add do help manage a little of this debt.

This member is usually covered in debugger fall out due to the limited tests they have been able to construct. The minimal coverage and paths their tests cover do lead to hours of howling and teeth-baring production debugging sessions. Often code added or fixed by this member leads to regressive defects.

They are unable to comprehend how these defects get into the codebase, as there limited brain capacity leads them to believe that their tests provide enough coverage to minimize risks. Time and time again this has proven not to be the case, but this member struggles to understand how!

Tribe ‘management’ see this member carrying out testing and consider testing to be a waste of time – due to the large number of defects still occuring. These ‘management’ members of the tribe do not see the quality of their testing as the issue, not the testing itself. This makes it extremely hard for more advanced members of the species to push for an increased testing focus.

This legacy of testing being a time-wasting exercise delayed the evolution of the Test Drviven Developer for some time. Thankfully some forward thinking members of the tribe ‘management’ team realised the errors of their way and led the acceptance of more evolved Test Driven Developers.

If you encounter one these members help them slowly comprehend development best practices, and point them in the direction of introductions to Test Driven Development such as Kent Beck’s Test Driven Development: By Example to assist them on their evolutionary journey. Then hope for the best, based on their limited learning capacity.

Human

Human

This member of the species is the earliest evolution of the modern test driven devloper.

This member sees tests as a way to exercise the code they have written. They write tests to check there code works as they intended it, a major shift in the evolutionary chain.

They write tests after the code and understand that testing their code, even if it is pure genius, will lead to less defects reaching production. They are capable of recognizing the need to test more than just happy cases too, including alternative cases to improve code coverage. Technical debt is more than just two words to this member, there focus on coverage helping add confidence in the technical quality of their code.

Whilst they lack understanding of development practices that could lead to more testable code, this member has also not connected the use of testing to drive design yet.

The test-after approach employed by this member does provide limited support for refactoring. Refactoring to this member involves changing code, not improving the code design. As a result refactoring often leads to numerous test cases being updated. This limits the value this member sees and gains from their refactoring methods.

The testing this member carries out does tend to result in less defects released into the wild. Many defects are found during local development supported by their tests and less regressions occur due to a vision of automating tests much like they had been doing with their builds for many years. This member rarely ventures into debugger territory prefering the safety of their test cases.

This member of the species is the leading member of the species population wise. For all their evolutionary advances such as test coverage, defect minimisation and understanding of technical debt, this member has missed the attention to business value that more evolved members have grasped. Their technical focus often leads to over-engineered solutions and unneccessary frameworks.

Tribe ‘management’ appreciate the reduced number of defects this member releases to production. A number of visionary managers are searching for more. These visionaries challenge members to visualize the business value they provide.

This members days as the most populous member of the species are numbered with the introduction and encouragement of more agile testing practices.

If you encounter any of the most populous members of the Test Driven Developer species inform him that TDD is more than a testing exercise, it has just as much to do with emergent design and get them to start reading about Test-Driven Design  in Neal Ford’s developerworks article from the Evolutionary Architecture and emergent design: Test-Driven Design, Part 1.

Developers

Developer

This member of the species is the first to exhibit an understanding of the design aspect of Test Driven Development (TDD).

Using test first development this member has come to understand that writing the tests first helps drive the design of their code.

They were the first members of the species to benefit from the leaner code base and improved business focus test-first provided. Technical debt is well understood by this evolutionary advanced member of the species, and coverage is just one of the many code inspections undertaken during development.

Refactoring to these members is more about improving design than changing code. They benefit from the capability to make more aggressive refactorings as a result of this understanding of refactoring. Code produced also tends to exhibit better design concepts and patterns as well as being more focused and leaner in format. Understanding of automated test techniques such as regression testing enables them to support purer design refactoring.

Another evolutionary shift achieved by this member is the behavioural nature of their testing. Behaviour Driven Development focuses on a Given-When-Then structure for test cases that this member has mastered. Behaviour testing focuses on what happens rather than technical mechanics enabling improved business focus. BDD enables teams to measure how much of the business functionality has been met.

These members rarely need to enter the evil lair of the debugger when fixing defects. They add tests that exhibit the defect failure and then fix the defect. They believe in the power of regression tests to prevent defects reoccurring and are very succesful in this area.

Tribe ‘management’ are impressed by the ability to measure the business functionality coverage, and the business customers appreciate the added value and  confidence tested behaviour provides them. This member of the species is highly sought after. Their numbers are increasing in the wild and the development family is all the better for that.

If you meet one of their increasing number out in the wild let them know that ATDD (Acceptance Test Driven Development) adds even more business value. Get them to order and digest the currently MEAP Specification By Example by Gojko Adzic.

Guru

TDD Guru

This member of the species has only recently been discovered. There numbers are minimal at the present time, and these members will be at a premium real soon.

Not only do these members use TDD as a design discipline and test exercise they have also quite amazingly been able to attach it to ongoing business value. They have been able to show the business value provided throughout the development cycle. This member uses the ultimate weapon in Test Driven Development, the latest evolution in TDD tools, the living document.

This living document uses specifications by example to exercise business facing tests with realistic scenarios provided collaboratively by the customer and development team. These bussiness tests build on the fundamental foundation of unit tests, these members recognise that test typers are not effective in isolation.

Adding new business value for these members  involves writing business facing tests, backed by technical unit tests. This methodology they have evolved encourages greater focus on providing business value as well as resulting in leaner code creation. These members are close to genius in capability.

This living document forms part of an Acceptance Test Driven Development (ATDD) methodology evolution this member promotes and encourages. The ATDD  methodology builds on the foundations of Test Driven Development (TDD)  to deliver code testing business specifications. These specifications exist in the living document recreated each time a build occurs, which means that this document is constantly relevant.

The living document is a live requirements document. Each version of the application has its own version of the requirements. Each version can be tested against it relevant requirements. This giant step in the evolution of TDD should not be underestimated.

These members almost always pick up defect prior to release, through the use of specifications by example, showcases and user tests. They recognise the value of collaboration during all aspects of the development process.

Defects that do slip through are quickly fixed and released through the use of continuous integration, regression tests and customer confidence. This member has mastered the skills that minimise the time from concept to release of features or defect fixes.

Debug is a dirty word to this member of the species. They feel violated when they need to use a debugger to fix issues – prefering the cleaner environment of the test case creation. They also utilise code inspection, coverage and regression tests to help them fix defects and maintain a managable level of technical debt.

If you come across this member, hire them quickly and monitor their evolution – what will be the next evolution in Test Driven Development?

Where do you sit on the evolutionary tree?

So where in the evolutionary tree do you or your developers sit? I have included a poll below to create a census of the current state of Test Driven Developers in the industry.

It would be great if you could spare 2 seconds to vote, and even better if you could take the time to comment on my interpretation of  Test Driven Developers evolution and add your thoughts and experiences of Test Driven Developers.

Test Driven Developer Evolutionary Tree Poll:

This developer quality tip is about keeping abreast with leading thinkers/players in your field. For me one of the leading thinkers in the software development field is Neal Ford from Thoughtworks. This tip relates to a topic Neal has been advocating since early 2009 – ‘Evolutionary Architecture & Emergent Design’.

Neal didn’t invent either concept, but is responsible for bringing them to my attention.

Evolutionary Architecture encourages the removal of big architecutural design up front, replacing it with architecture that evolves alongside application developement. Martin Fowler had argued this as part of this XP inspired 2004 paper – Is Design Dead?.

The philosophy of deferring commitment for dealing with the unknown has successfully enabled the most difficult journeys

- Emergent Architecture, Running Agile – A Practicioner’s View to Lean & Agile (Jan 2008)

Emergent Design relates to the use of TDD (Test Driven Development) as a design exercise in order to create more maintainable code. Patterns that emerge lead to refactoring exercises providing a leaner codebase.

One of the difficulties for emergent design lies in finding idiomatic patterns and other design elements hidden in code

- Neal Ford: Emergent design through metrics (Mar 2010)

Neal Ford’s developerworks articles are listed and linked to below. Searching for all of the articles on developerworks and the link provided by Neal himself in his presentation (link below) fails to list all the articles – so I have included them here for your convenience.

Evolutionary Architecture & Emergent Design
Neal Ford – Developerworks Series

• Investigating architecure and design
• Test-driven design, Part 1
• Test-driven design, Part 2
• Composed method and SLAP
• Refactoring towards design
• Language, expressiveness and design, Part 1
• Language, expressiveness and design, Part 2
• Harvesting idiomatic patterns
• Evolutionary architecture
• Emergent design through metrics
• Leveraging reusable code, Part 1
• Leveraging reusable code, Part 2
• Using DSLs
• Fluent interfaces
• Building DSLs in Groovy
• Building DSLs in JRuby
• Environmental considerations for design, Part 1
• Environmental considerations for design, Part 2
• Emergent design in the wild

Neal Ford has presented his ‘Evolutionary Architecture & Evolutionary Design’ several times. Below is a link to one of these presentations on Vimeo:
Emergent Design – Neal Ford from Michael Tiberg on Vimeo. I would have liked to have embedded this video here, but was unable to do so due to permission issues.

The are numerous other resources I could add to this list, but why re-invent the wheel when Brad Appleton’s ACME Blog: Emergent Design & Evolutionary Architecture resources entry has many of the best listed already. I urge you look through his list and read those that you find relevant.

I would also appreciate anyone aware of recent discussions on ‘Evolutionary Architecture & Emergent Design’ to list them in the comments below – and I will endevour to add them to the list on this page.

Finally, once more, I encourage you to keep abreast of the leading thinkers/players in your field.

Doing it wrong!!

I have an almost unhealthy infatuation with productivity and ways to improve it!

It begun many moons ago with a to-do list written on a scrap of paper. I started writing to-do lists for all kinds of things. What I planned to do at work each day became a to-do list. Things I planned to do around the house became a to-do list. As many others before me, I learned that having a to-do list itself doesn’t result in improved productivity.

Sure, I got things done and felt a sense of achievement, but I constantly felt frustrated by the number of incomplete lists. My infatuation with improving my personal productivity had begun.

My first improvement was to introduce prioritization. I was now getting the most important things done all the time. Unfinished things now seemed to find their way to the top of the next list!

My prioritization criteria needed some improvement. I begun to notice a trend too, many things on the lists were getting started but not finished. There seemed to be a lot of opportunities for improvement at this time.

I then discovered Remember The Milk an on-line to do list. Now I was able to categorize as well as prioritize tasks (my new terminology for things). It felt like an improvement, but I was never totally convinced!

I no longer lost unfinished tasks, I could view completed tasks and visualize task history. The number and types of task completed within time-frames gave me new data to analyse. I begun tracking task velocity based on type and availability in a crude manner.

For a while the online, categorized, prioritized to-do list became my tool of choice. Tweaks were made to the process, dependencies on other tasks, time-boxed tasks, shared tasks amongst them. There still seemed plenty of opportunity to improve.

Recently it has been replaced. Prior to Christmas a work colleague introduced me to Personal Kanban.

Kanban Wall - 'Home'

After the introduction I spent time discovering what Kanban was. I read about the techniques people used and now have  a number of Kanban walls – at work, in the garage, and on my mobile phone! I feel I have moved to the next level of productivity as a result.

Who would have thought such a simple concept could have such an impact on productivity. The concept - limiting the work in progress.  Improved focus on a limited amount of tasks results in more getting done. How had I not considered this before? No idea – but I am glad someone else had.

I soon desired mobile Kanban walls. KanDroid for Android seemed to fit the bill. I could add tasks, limit my WIP (Work in Progress), and mark tasks as done. It has one fatal flow. There is no way to prioritize items in the backlog!  Prioritization was a vital part of my productivity, which means I am seeking a more suitable implementation at this time.

Now that I have Kanban in my toolkit I do feel more productive. The constant strive for improved productivity doesn’t end though.

Most items in my backlog seem to be stories. Each story requires a number of tasks to be completed. I initially tried managing these tasks using online to-do lists. Currently I manage tasks using a mobile task management application. It does not feel ideal, so I am looking for ways to improve here. (Experimenting with post-it tasks on one wall – see image above).

My constant strive to improve productivity continues. I am always interested in hearing about ways other people strive to do this too.

It's not 'ALWAYS' the testers fault...

…that your software doesn’t work!

I’m not saying it’s never the testers fault. What I am saying is this. It is not just the testers who contribute to the success or failure of your software.

• How can this be the case?
• Who contributes to the success or failure of your software?
• What can be done to improve the chances that your software will be a success?

Product/Business owners….Lets discuss it!

This is the 2nd of 3 discussions around the roles and responsibilities of the Product/Business owner in the agile software development life-cycle. In this 2nd discussion I will look at the roles and responsibilities of the team members at the iteration level. In a previous discussions I looked at their roles and responsibilities at the project level (It’s not ALWAYS the developers fault…). In the final discussion I will look at their roles and responsibilities in the story delivery life-cycle.

How can this be the case?

The testers are responsible for making sure things work as expected. It is there job to find all of the things that are wrong with the software. How can it not be there fault?

During iteration ‘zero’ test script frameworks related to identified stories will be decided upon by the testing team. Testing spikes may be identified and addressed if the need exists. Collaboration between the developers and testers will be required to ensure spikes are identified and suitable test frameworks selected.

Along with the team a definition of done will be decided on during Iteration ‘Zero’, so although the testers decide on the tools/frameworks they will use, the team decide as a whole when something is considered done.

Prior to the iterations some story elaboration may take place. Early story elaboration (1 or 2 iterations in advance), can help to minimize time spent elaborating on stories during iteration kick off. Involve the appropriate team members in early elaborations.

Other forms of testing such as performance, load and exploratory testing may also be included in the test strategy. Scenario testing is usually developed in collaboration with the BA & SME based on available features – again collaborative in nature.

During iteration kick off the stories planned for the iteration should be workshopped with the whole team present. The whole team should have an understanding of the stories being delivered. Testers get to understand the other team members view of the stories and provide their own views too.

Test plans for the iteration may be updated/prepared based on the planned stories. Test plans may be no more than testing all the planned stories, but performance and other specialised forms of testing may be included in the plans.

As can be seen, what is tested during an iteration by testers is largely dependent on what the whole team has planned and elaborated on.

The iterative implementation stage is where most effort is targeted. Testers are responsible for creating and implementing functional test cases at this stage. Testers are also responsible for testing the cards as functionality is delivered – as per the test plan agreed on by the whole team.

Testers are not responsible for unit tests, or for writing the functionality being tested. Throwing untested code to testers does not make them responsible for testing at a lower level. Developers have to take on responsibility for quality, shared with testers, as part of a team wide effort to provide good quality.

During close out testers take part in the retrospective along with the rest of the team, as well as attending the iteration showcase. The testers also provide test reports and measurements for use in metrics during close out.

Testers are not the only contributors at the retrospective, they also sit back and absorb information from stakeholders at the showcase – rather than make decisions/comments. So although the testers are responsible for checking that the software meets customer expectations, they are not the only people to ensure this is the case.

Who contributes to the success or failure of your software?

If the testers are not the only ones responsible, then who else is? Who else contributes to the success or failure of your software?

The project management has an important role to play during iteration ‘zero’, that of team set up and structure based on the project plans. The whole team is responsible for agreeing to the definition of done and beginning the elaboration of stories for the initial iterations.

Developers are responsible for sharing technical spike information, naming conventions and low level design decisions with tester. This will help testers make informed tools/framework decisions. Collaboration is also essential across the team in setting up tools and environments like defect trackers, build environments and other tools.

The whole team have a role to play in iteration planning, the tester being just one of them. You as the product owner/sponsor, the BA, SME, developers and the infrastructure team all have a role to play during iteration planning. The team should participate in deciding on what will be included in the iteration and plans for deployment.

Each member of the team brings their own skill set to the table in planning and elaboration meetings which is important. Each also has a responsibility to contribute and ensure their voice is heard at this stage of the iteration.

At the iteration kick off all team members elaborate the stories planned in order to get a shared understanding within the team. Collectively the team have shared responsibility to agree on acceptance criteria for each story being delivered. The whole team are responsible for delivery of each story.

The whole team play a role in planning what they hope to accompolish during the iteration at kick off. Walls and BVCs should be updated by those responsible for them, ready for implementation.

Developers and the use of TDD – from a design and confidence to refactor the codebase, play a significant role during implementation. Unit level testing provided by the developers builds a foundation for the functional tests written by the testers. Without this base, functional testing is likely to be compromised at a lower level.

The whole team has a role to play in ensuring quality practices are undertaken. Unit and functional tests need to be run regularly. Deployments should be done as agreed during iteration planning, providing enough time to test and fix issues. In addition UAT needs to take place to enable invaluable user feedback.

During close out all team members have a responsibility to be open and honest at the retrospective, sharing both the worst and the best of the iteration. Stakeholders have a responsibility to attend the showcase, provide valuable feedback and confirm the software meets customer needs.

What can be done to improve the chances that your software will be a success?

So if there are so many people contributing to the softwares success, what can be done to improve the chances of success?

Don’t underestimate the importance of iteration ‘zero’, use it to eliminate as much risk as possible. Utilizing this iteration to set up the team (co-location preferred), to perform technical spikes and initiate planning and story elaboration will set your project up for success.

Iteration planning involves many people in many roles with many responsibilities. To get the most from each iteration try to plan story elaboration 1 or 2 iterations in advance. Review those present in the current iteration at the planning meeting.

Prior to the iteration start re-emphasize the definition of done, so that the team are all on the same page. Planning of long lead tasks such as deployment tasks can prevent delays during the iteration if included in the planning. Iteration planning deserves to be given the respect it deserves, so don’t try to rush this phase.

At the iteration kick off, ensure the whole team are present and understand the scope of work to be delivered. Use the kick off to make sure all members of the team have a shared understanding of the in scope stories.

Ensuring TDD occurs, utilisation of pair-programming and code-reviews can help improve coding standards during implementation. Unit and functional tests should be integrated into a continous build cycle, triggered by code check-in to source control. These practices will provide quick feedback time for quality issues.

Deployments to integrated environments enable testers to work in stable environments. Regular deployments can help to minimise environmental issues that only show themselves in more production like environments. UAT helps identify user issues prior to release, and helps improve the user experience based on feedback.

During the close out ensure the whole team participate in the retrospective. Ensure that actions that come out of the retrospective are assigned, and make sure these actions are followed through.

Ensure all stakeholders are present at the showcase, so that they all have the chance to contribute in the provision of feedback early in the process. These showcases can prevent potential pitfalls late in the project schedule.

Build Quality In

As we have seen quality is the responsibility of every team member in an agile team, not just the testers. Every team member has a role to play in building quality in.

Are you ready yet to admit…it’s not ALWAYS the testers fault?

Writing Computer Code

This is the first in an ongoing series of tips for improving developer quality. Each tip will highlight development skills that I believe help improve code quality. Skills developers can learn via the resources linked to in the tip. Skills that once mastered will lead to better quality solutions.

#1 Transaction Models & Strategies

This first tip looks at transactions. Good developers can tell you that transactions need to have ACID (atomic, consistent, isolated and durable) properties. They will also be able to tell you that transactions help recover from failures and help to keep the data in a consistent state.

How many developers in your team can explain commonly used transactional models and strategies?

Lets start with the transactional models. If your developers have never heard of the Local Transaction model, the Programmatic Transaction model or the Declarative Transaction model then a good starting place is the free PDF book ‘Java Transaction Design Strategies’ by Mark Richards available on InfoQ.

Moving on to transaction strategies Mark Richards has written a series of article on developerworks. So if your developers have not heard of the Client Orchestration, API Layer, High Concurrency or High Speed Processing transaction strategies then this series will help them get a heads up:

• Transaction strategies: Understanding transaction pitfalls
• Transaction strategies: Models and strategies overview
• Transaction strategies: The API Layer strategy
• Transaction strategies: The Client Orchestration strategy
• Transaction strategies: The High Concurrency strategy
• Transaction strategies: The High Performance strategy

Spring is used in many of the examples throughout the PDF book and developerWorks articles. As Spring is so widely used it is also worth reading the Transaction Management section of the Spring Reference Guide.

For those still wanting more – Java Transaction Processing: Design and Implementation seems to be the recommended book on this topic (I had not read this at the time of writing – but it is on my list of books to read).

Hopefully, this tip and these resources will encourage more developers to think about the transaction model and transaction strategy they are using on their current/next project.

This information should help developers pick the best model and strategy based on their project requirements. They will be able to explain the reasons for their choices and describe the advantages of the chosen solution over others.

If you have any other useful resources related to this tip please add them in the comments.

]]> http://www.catosplace.net/blogs/personal/2010/10/22/improve-developer-quality-tip-1/feed/ 0 http://www.catosplace.net/blogs/personal/2010/10/11/always-developers-fault/?utm_source=rss&utm_medium=rss&utm_campaign=always-developers-fault http://www.catosplace.net/blogs/personal/2010/10/11/always-developers-fault/#comments Sun, 10 Oct 2010 11:32:36 +0000 Peter Sellars http://www.catosplace.net/blogs/personal/?p=580 Continue reading →]]>

It is not 'ALWAYS' the developers fault.....

…that your software doesn’t work!

I’m not saying it’s never the developers fault. What I am saying is this. It is not just the developers who contribute to the success or failure of your software.

• How can this be the case?
• Who contributes to the success or failure of your software?
• What can be done to improve the chances that your software will be a success?

Product/Business owners….Lets discuss it!

This is the 1st of 3 discussions around the roles and responsibilities of the Product/Business owner in the agile software development life-cycle. In this 1st discussion I will look at the roles and responsibilities of the team members at the project level. In subsequent discussions I will look at their roles and responsibilities in the iteration and the story delivery life-cycle.

How can this be the case?

The developers are responsible for engineering and writing the software that you ask for. How can it not be their fault?

During the project concept phase developers have no roles or responsibilities at all. It is not the developers who decide if your project is feasible. A technical lead/architect will be involved in the high-level design, but the decision on proceeding with the project does not rest on them.

The initiate phase sees the granulation of concept level work. Developers along with other team members participate in workshops at this phase. The developers play a role in helping to break down features into stories and refining the solution design among other things. Their role in these workshops is the same as every other team member present – to  refine the concept.

Developers may carry out technical ‘spikes’ around technical risks to help determine estimates and time frames, but for the most part they are merely members of a team identifying, prioritizing, estimating and planning at this stage.

Development is carried out by developers at the develop phase of the project. No prizes for getting that one right. Is this when it becomes their fault?

Well, once again they are not the only members of the team involved in this phase. They are part of a team charged with building functionality that adds business value, and they need support from other team members to do this. The whole team should be involved in planning sessions, stand-ups, retrospectives and showcases during short iterative periods of development.

Developers play a large role in engineering functionality at this stage. It is there responsibility to develop code that meets acceptance criteria established by the whole team. This same code is tested manually by test analysts and demonstrated to you before being considered complete. That means everyone in the team has agreed what the developer should build, it has been tested and has been accepted by yourself.

Development is not carried out in isolation, the whole team is responsible for ensuring its quality, not just the developers.

Finally there is the deploy phase. Here the developers have a role to play in handover to the production support team. They will also be involved during creation of the back out strategy, data recovery and stress testing.

The developers role at this phase is largely supportive. Once more, this phase relies on team efforts – not just the developers.

Who contributes to the success or failure of your software?

If the developers are not the only ones responsible, then who else is? Who else contributes to the success or failure of your software?

Typically the BA (Business Analyst), SME (Subject Matter Expert) and a technical lead/architect will take part in workshops during the concept phase of your project. These team members are responsible for formulating the desired outcomes, identifying features as well as preparing some high-level design and estimates. Their role is to determine if the initiative is worth doing.

As well as the BA, SME and a technical lead/architect, the developers and test analysts will all be involved at the project initiation phase. Every one of these team members has a role to play in adding detail to and refining the conceptual phase outcomes. Each team member is responsible for utilizing their unique expertise to elicit stories, prioritize, design, estimate and plan during a series of workshops.

So who else contributes during the develop phase? Strange as it may sound the BA, SME, test analysts and a technical lead/architect have just as much to contribute during this phase as previous phases. Infrastructure also become involved at this phase – as a focus starts to be put on deployment and production support.

Each team member attends planning and story elaboration sessions, stand-ups, retrospectives and showcases. Each has a responsibility to contribute their skills, even during the feature development cycle (which we will discuss further at a later date).

Test Analysts have a responsibility to test features as they are developed. You are responsible for agreeing that the acceptance criteria is met during a demonstration/showcase. You have a role to play in the quality of your software during the development phase.

During the deploy phase the SME, Test Analysts and production support teams all have roles to play. The main objectives of this phase are to move to a production environment, whilst ensuring a good handover to the production support team.

Handover to the production support team occurs with support from developers. Final user acceptance testing occurs at this time. Data Recovery, stress and load testing will be carried out by Test Analysts during this phase.

What can be done to improve the chances that your software will be a success?

So if there are so many people contributing to the softwares success, what can be done to improve the chances of success?

Use the project concept phase to determine if it makes business sense. Ensure the business benefits exist to make the project worthwhile. Establishing SMART (Specific, Measurable, Attainable, Relevant, Time-Bound) goals and completing value sliders at this stage will enable you to measure project success. Tying features to business benefits helps prioritize implementation. Ensure diligent risk analysis is carried out too.

Even at this conceptual stage there is a serious chance of impacting project success. Don’t take it for granted. Use it to your advantage.

At the initiate phase of the project involve the whole development team. Ensure identified features are broken down in to stories. Map the stories to the business processes to ensure nothing is missing. At this stage prioritize the stories based on MOSCOW (Must have, Should have, Could have, Wont have). Prioritize on business value not effort or complexity. Also carry out risk analysis on the stories and plan to deal with high risk ones in early iterations.

During the initiate phase prepare the test strategy – the what, when and how of testing. Estimation plays a big role at this phase. Estimation workshops carried out now help you produce effective plans. The estimates, plans, risk analysis and prioritizing all have an impact on the projects chances of success. Utilizing the teams combined skills improves your chances of success – even before development has begun.

At the development phase, ensure developers use ATDD (Acceptance Test Driven Development)/TDD (Test Driven Development) methodologies. The ATDD/TDD methodologies combined lead to leaner code, written when needed, that meets acceptance criteria. Developers doing this, will improve your chances of success.

Around the development cycle in this phase ensure iteration planning and story elaboration involving the whole team take place. Create a shared level of understanding about goals and stories throughout the whole team. Don’t neglect the retrospective, and the chance it provides to review, action and implement changes to help the team succeed.

The aim of the develop phase is to produce working software at the end of each short iteration. Hold a showcase, highlighting the new features. The showcase also enables your team to get early feedback on developed features prior to release.

The deploy phase needs to be started well in advance to be successful. Engage the production support team early. This will help to make the handover smoother. Carry out data recovery and stress testing during the deliver phase, providing the team time to identify problems and fix any issues.

As this phase often involves tasks that take a lot of time, plan to do as many of the tasks as possible during the deliver phase. Addressing these tasks early offers the best chance of a successful deploy phase.

Build Quality In

As we have seen quality is the responsibility of every team member in an agile team, not just the developers. Every team member has a role to play in building quality in.

Are you ready yet to admit…it’s not ALWAYS the developers fault?