Agile

Agile Alliance Brisbane: Changing Role of a Tester

/ Craig Smith / 2 Comments

The inaugural Agile Alliance Meetup in Brisbane kicked off on May 13 at the Hilton, Brisbane with a talk by Kristan Vingrys (Global Test Lead for ThoughtWorks) talking about the changing role of a tester. I have had the good fortune to work with Kristan a couple of times this year, so was looking forward to catching up again as well as seeing this talk.

Among other announcements, Robin Mack is the Brisbane liason for Agile Alliance Australia and they are currently looking for volunteers, sponsors and speakers.

The following are my notes from the session, the slides are also available online:

Agile Alliance Brisbane Kristan Vingrys

  • testing – find out what system is and what it does
  • testing is not about putting a quality assurance stamp on software before it goes out the door, its about understanding the quality of the application
  • traditional testing – V model – independent, based on a feature complete system, exit criteria from each phase
  • collaboration – more related to agile – single velocity for entire team (not just developers), co-located and interspersed team, loose boundary of roles, work closely with developers (not throwing information over the wall)
  • should not be iterative testing (testing 2-3 iterations behind), independent or separate velocity
  • stop finger pointing, no longer a gatekeeper
  • tester should be able to check out code, try it out whenever they want to
  • tester should have direct contact with business to break down direct animosity with the developer
  • measured by value added to the team not by defects found or number of tests written
  • test early – make sure the story is testable, do all testing earlier (including non-functional testing such as UAT)
  • Acceptance Test Driven Development – building quality in, not testing it in, this is not just about automation
  • handover – developer should call tester over to ensure that the requirement has been met, give the tester the keyboard for 2 minutes to see if they can break it before check-in
  • exploratory testing – difference between exploratory and ad-hoc, it should have a plan, allows to execute test cases while learning the system, a good approach to test the tests, looking for different ways to learn about and break the system
  • automation – a good way to continually do regression testing, it is not a test strategy, is not just tests (can also be used for automated assisted testing, trawling through log files, etc), automation is code so treat it like code (not using good behaviours will end up as brittle code)
  • unit testing – benefits the tester, know what comes from the developers has been tested to a certain level
  • continuous integration – push the regression suite so that it becomes the responsibility of the team
  • pairing – way to transfer knowledge, to and from the tester, focus on higher value testing
  • co-location – can talk directly to the team about issues or further understanding
  • standups – understanding what the team is doing, what they are working on, know areas of system to spend time on or stay away from
  • automated functional testing – not running the same test again and again and again
  • ratio of testers to developers – hard to gauge, depends on the skills, not everybody on the testing team needs to be a tester
  • test analysis – what are we going to test, understand requirements, architecture, test execution (by a human or a machine), environment management (testing the right thing, a stable environment)
  • “you can’t find a defect if it doesn’t exist”
  • troubleshooting – being able to track down a problem, find the artefacts and hand it off to the correct team to fix
  • every role on the team should contribute to testing in some way
  • metrics that you collect change when you move from waterfall to agile testing
  • generating a test report should not take very long – should be an indication as to whether someone needs to have a conversation with me, answers questions about the state of the test team
  • people make assumptions on vanilla metrics

Metrics:

  • points in test over time – number of stories that are in the testing column on the storywall, indicate if the team is keeping up with testing activities
  • outstanding defects over time  – how defects are tracking over time
  • number of bounces per story point – bounces back and forward between the development and the testing columns
  • not all defects need to be logged – only needs to be captured if it is not going to be fixed straight away, better to spend time on automated test to check defect will not come back rather than logging it
  • be aware of fake defect debt – when a story gets pushed through and defect/s get raised to be fixed later
  • add value by getting team focused on quality

Then there were some questions from the crowd:

  • environments – want enough environments to avoid test scheduling (where possible), happy to do UAT in an earlier environment if it means you are getting early feedback that is useful
  • tester velocity – should be focused on the velocity of the team and the definition of done, investigating using Kanban techniques to set a limit on a column (perhaps for testing to enable team flow)
  • automated tests – depends on where business logic, for AJAX you need to do more UI tests, main issue is getting tests running as quickly as possible and getting fast feedback, prefer not to test via the UI because it is very fragile
  • skillsets – pulling a team together will look at troubleshooting and may need to hire somebody just for this task, a team with developers that strong minded makes it hard for a tester to get their opinions across
  • test plans – does not necessarily need to be a document, the important thing is that there is a shared understanding, should never be signed off because it should be constantly revisited
  • skilled team of testers and developers – who should write the automated tests – look at skills, should not be written by those whp do not understand programming or test analyst – answer what I want to test and how do I go about developing it
  • regression test definition of done – business need to articulate the level of risk they are willing to accept, understand where the business value is in the system, finding a defect may encourage you to spend more time

 

Thoughtworks Quarterly Briefing: Emergent Design & Evolutionary Architecture

/ Craig Smith / 1 Comment

Yesterday ThoughtWorks held a quarterly briefing in Brisbane for which they shipped out Neal Ford (who I had seen speak at Agile 2008 previously). My notes from the breakfast session are following. I was also lucky enough to get invited to a roundtable lunchtime one-on-one discussion with Neal and a handful of my peers from Brisbane, which provoked some great discussion.

Emergent Design & Evolutionary Architecture - Neal Ford (Brisbane)

My key takeaways were thinking about design like a lossy compression algoritm (it’s a good analogy about the loss of clarity), the secret to winning Pacman and the insight (from the lunchtime session) that Flickr have got continuous deployment down to 30 minutes (impressive!)

The slides for this session are available on Neal Ford’s website and via Slideshare.

My notes:

  • basis for this talk comes from a number of IBM developerWorks articles by same name
  • emergent architecture – bad idea, because you need something to build on
  • spectrum of design – from waterfall to cowboy hacking, agile design is somewhere in the middle
  • big design up front – a bit like trying to reconstruct a picture that has been through lossy compression, you lose the clarity
  • emergent design (hardware) – Apple iPod click wheel – refactored, but you had to buy a new ipod to get the updated functionality
  • patterns – technical (plumbing) and domain (business logic) – defines abstractions
  • avoid abstracting too early – speculation, YAGNI, business changes radically, experience helps to identify these (architects)
  • What is Sofware Design? (Jack C. Reeves, 1992) – proves we just reinvent the same thing over and over in software
  • final delivery for engineering is a document (because you are designing a bridge, not building it), The design document in software is the complete source code (source == design)
  • manufacturing is the build process – in Java/.NET this is free, and happens automatically
  • in software, everything is part of the design process – code, test, debug
  • software cheap to build but expensive to design

Things that obscure emergent design:

  • complexity – essential (inherent) and accidental (we usually take a simple problem and accidentally make it complex) – what we imagine and what results are different (field level security example)
  • technical debt – gap between design you imagined and design you got (usually due to schedule pressures), debt is not a bad thing unless it gets out of control, so in software you need to negotiate repayment
  • negotiate repayment – hard to convince management, demonstration trumps discussion eg. cyclomatic complexity per tag / branch of code (proved that we made the date but the effect that had on the code)
  • genericness- building in layers, just in case

Things that make emergent design easy:

  • test driven design – design emerges from tests, undertanding of intent and allows you to measure it, exposes design flaws early and allows refactoring (Neal has a talk specifically on this subject)
  • refactoring – encourages collective code ownership, fix broken windows (from “The Pragmatic Programmer“), prudently refactor aggressively (fix small problems at the time they are discovered otherwise create a technical debt backlog – assign a pair that does this for the entire iteration), code should get stronger with age

Metrics

  • cyclomatic complexity – measures complexity of function based on branches and decisions
  • afferent coupling – how many other classes use this class, shows the centre of the code base – ckjm (Java), showed an example across the Struts codebase
  • expressiveness – neads to be readable, comments not executable and always out of date – Java vs Groovy and Ruby example (no closures vs closures)
  • abstractions – Pacman example – intelligence built into maze (a large state machine), ghosts use Pacman smell (can’t tell where Pacman is going, only where he has been)
  • framework level architecture – you download a library, usually not a single class, JSR294 solves this in Java (have done this with Ivy and Maven previously)
  • “architecture is the stuff that is hard to change later” (Martin Fowler see his article “Who Needs An Architect?“)
  • politics of architecture (usually because architects are senior), build vs buy (generic software with a few tweaks is usually just a myth because software can provide a strategic advantage)
  • design == code, always try to leave decisions until the last responsible moment

Agile Academy Meetup: Usability & Clouds

/ Craig Smith / 3 Comments

MeetupAgile AcademyThe Agile Academy runs a quarterly meetup in Brisbane and held a meetup this week on usability, whilst their meetup in November was on Cloud Computing. Here is my wrapup:

Agile Is From Mars, Usability Is From Venus

  • lots of good agile usability discussion started by Jeff Patton on the agile-usability group
  • cobbled together design forces usability not to have the incremental design it needs
  • coding is creative, the only thing mechanical is compiling
  • be a tribe leader and collaborate, suggested reading is Tribes by Seth Godin. Teale recognised by her managers for her leadership for getting out there and posting to the internal Yammer site
  • goal directed design, focus on the goals of the user – design applications in terms of needs and goals and underlying motivations, so when the transport or technology changes, the design work is still relevant
  • poetpainter.com (Stephen Anderson, Interaction Designer) – who are we designing for and what are we designing for, fundamentals of experience design (http://www.poetpainter.com/thoughts/category/Models–Frameworks/)
  • get into the head of users with user needs – motivation keywords to articulate user needs – increase positive aspects, maintaining status quo and decrease negative aspects – flopped as a workshop but worked wonders as a survey (and surprised the business as to the candid responses from the users)
  • user goals – who I want to be (life goals), what I want to do (end goals) and how I want to feel (experience goals)
  • use success sliders to understand how important the project team view usability
  • personas – need to have understanding of users and need to do impact analysis
  • storyboards do not need to be neat, just a rough drawing to determine if you are hitting the mark
  • put the name of the persona in the storycard (not just the role) such as: As a [role of user] [name of persona]…
  • use MOSCOW (Must, Should, Could, Won’t) for prioritisation
  • 960 grid system – consistent framework for screen design
  • parallel track system – designers one iteration ahead of developers and business two iterations ahead of developers
  • the featuritis curve – more features you add, the harder it is use
  • 5 second usability test – realise that the middle part of the page is the most important part of the page, helps business understand where to put content – see http://fivesecondtest.com for example, but Teale creates her own with PowerPoint
  • for more on usability testing read the Handbook of Usability Testing or use TechSmith Morae (but this is very expensive)

From the question and answer session:

  • hard to manage parallel development two iterations ahead because stories always change, Marina Chiovetti added that research suggests this only works for a maximum one or two week sprints/iterations whilst Phil Abernathy suggested that the use of usability frames means that screens are being tested with the users upfront
  • Tealse does not use wireframing tools but rather does these in a workshop by hand. She only uses Adobe Photoshop when needed. Someone suggested that Adobe Fireworks is also a good tool and has templates on 960 Grid System
  • PAC analysis – People, Activities, Context

Agile, Lean & Green IT Come Together

Gavin Keeley presented at the Agile Academy November 2009 Meetup:

  • President Obama mentioned green as much as the global financial crisis in his innauguration speech
  • commerical use of IT is responsible for 2% of CO2  emissions, larger than the airline industry
  • of all PCs in use, only 6% of capacity is utilised
  • power is the biggest issue for data centre managers – can’t get enough off the grid
  • Suggested reading: Green To Gold by Esty & Winston
  • Amazon is the poster child for cloud computing, issues with latency in Australia thoughcloud – getting capacity just before you need it
  • agiles final frontier – how do we get colleagues in infrastructure on the journey with application developers
  • VMware at Virtualization Forum 2009 – View, vSphere, vCloud, vApps (what was Spring) – 85% market share
  • Microsoft Windows Server 2008 Hyper-V also on the bandwagon
  • Xen – open source virtualisation technology – Oracle only allowing certification on Xen
  • latest buzzword – the software mainframe – that’s restrictive, how about the software data centre
  • 3tera doing interesting things in the grid space

ASWEC 2009 Wrapup

/ Craig Smith / Leave a comment

ASWEC 2009Earlier last year I attended the Australian Software Engineering Conference (ASWEC) on the Gold Coast. I recently had to dig up my notes when creating a summary of my year in Agile (2009), and, since the conference was before I started blogging in anger, I decided to post up my notes now.

My impressions of the conference was that whilst its theme was “Agile, the New Mainstream”, many of the core attendees (mainly from the academic and research environments) were relatively unaware of agile in practice. My core criticism was that unlike other conferences I have presented at, this conference requires the speakers to still pay to attend. Luckily my employer was a sponsor and negotiated a free pass, but for this reason I did not submit a proposal for the ASWEC 2010 conference that is being held in Auckland, New Zealand.

ASWEC 2009 - Agile Academy

The following are my notes from the sessions that I attended.

Keynote: Specialization and Economies Of Scale

Mary Poppendieck delivered the day 1 keynote:

  • deal with complexity? – divide and conquer – along what lines do we divide?
  • “The Pin Factory” (Adam Smith, 1776) – divide by specialisation
  • 1930, Ford – the ultimate pin factory – variety is the enemy – a car for every purpose
  • cost of changeover – batch and queue – $ cost to change machines over, Little’s Law (queuing theory)
  • cost of delay – cash flow, obsolecence
  • cost of mistakes
  • cost of motion
  • cost complexity – scheduling, learning
  • use a work cell instead of economies of scale – relied on cross functional team
  • 1968, Edsker Dijkstra defined structured programming and proclaimed need to eliminate bugs to start with, the programming will be cheaper
  • 1972, Harlan Mills defined top down programming – should not have difficulty at integration
  • divide by hierarchy / organisation
  • 1972, Dave Parnas defined criteria for decomposition – modular programming, easier to change
  • 1974, Vint Cerf / Robert Kahn invented TCP/IP – each network stands alone, no information retained by routers, no global control, communications on best effort basis
  • division by matching the domain

Amazon – all about scale

  • transitioned to services, each one
  • owned by two pizza team – must be able to feed the team with two pizzas
  • eliminated communication between teams, seven people cradle to grave, cross functional, stay a minimum of two years
  • now sell as cloud computing
  • like TCP/IP, don’t need to reach agreement – eventual compatibility, don’t worry about different databases, accept and deal with failure
  • software structure meets organisation structure
  • teams need independence to be creative
  • Conway’s Law
  • 1976, Barry Boehm – SDLC – specialisation (like Ford)
  • IBM – convert 35,000 engineers world-wide to agile
  • WebSphere – 10 month deadline, customer feedback every iteration, early access program, customer feedback on discussion forum – 50% of marketing information wrong so developers listened to customer – phenomenal sales day one of release, support calls down by an order of magnitude
  • case study – do agile right and find defects the minute they happen
  • xUnit testing – one of the best software engineering advances in the last decade
  • batch and queue so ingrained, we fail to see queues of work that will take years to clear
  • utilisation paradox – 100% utilisation of highway is a parking lot
  • Empire State Building – September 1929 to May 1931 – on time and 18% under budget, demolition to finish – biggest issue was supply of materials, the only thing that was scheduled (Carol Willis, “Building The Empire State” builders notebook)
  • 4 pacemakers to build the building
  • schedule the constraint – use a pacemaker schedule for the constraint

Towards Specification Based Testing for Semantic Web Services

Gill Dobbie delivered this presentation:

Intellectual Property In The Software Industry

I always enjoy presentations on the legal side of IT, and Alistair Smith delivered this informative presentation:

  • 4,000 patents last year to IBM, USA has the most number of patents
  • copyright protects the expression of an idea, not the idea itself
  • patents protect products, methods or processes – jurisdictional (so need to apply multiple times)
  • confidential know-how – not known to the public (eg. the recipe for Coca Cola)- work must be secret, can be leaked
  • trademarks – distinguish goods / services of a trader, Coca Cola 80% is recognition of product – must be distinctive, reproducible, people trading for smells (tyres that smell like roses), can be renewed indefinitely
  • strong protection – need range of IP types
  • do an R&D review eg. Kambrook and power boards
  • patent pending – filed but not yet granted
  • open source and patents do not mix – but use other IP
  • reward inventors
  • formalise IP ownership – make explicit in employment contracts
  • review existing IP – company that had patent for JPEG compression missed 10 years of royalties
  • maintain records of R&D – evidence of inventorship, ownership and prove date of creation for copyright purposes – maintain previous versions of software in unchangeable form, keep notes in bound notebook, dated and signed
  • search IP databases – look at what competitors are doing
  • use trademarks that are registerable – not descriptive  of product, should be distinctive
  • don’t just rely on copyright – does not protect against independent creation
  • don’t rely on confidentiality agreements alone – provides very little protection and hard to prove and hard to recover from
  • don’t rely on open source software being unencumbered by patents eg. Microsoft has 200 Linux patents, IBM “bluewash” on its new takeovers and check code line by line (takes six months)
  • no 10% rule on copying software – infringe is a substantial part – 2 JS/CSS files in a content management system
  • don’t forget to mark products – impact on damages

Invited Presentation: Bringing Agile To Life At The Enterprise Level

ASWEC 2009 - Jeff Smith

Jeff Smith, the CIO of Suncorp, delivered this keynote presentation:

  • feedback is essential
  • Wikipedia – 6 employess, 200,000 hours of contribution from community
  • Grateful Dead – high grossing band, found people like listening to music together, “collaboration”
  • leaders need to encourage simplicity
  • provide tools to enable collaboration
  • leaders use passion not threats to get things done
  • innovation / entrepreneurship is for everyone – need to channel the passion
  • Pixar – core beliefs, simplicity, intellectual capability
  • managers need to help teams get out of failure
  • trusted environment – safe to tell the truth, create a learning environment
  • creativity for everyone not just the artists, focus on people not the ideas
  • disseminate the authority to the teams
  • similarities between Pixar and agile
  • get people interested in learning
  • why? why now? why do it this way?
  • we are good at reacting, not so good at responding, initiate change is hard
  • generosity is hard – right for community before yourself
  • managers have employees, leaders have followers
  • culture top down, innovation bottom up
  • fear of failure – actually fear of blame / feedback, very few people fired due to a failed project
  • worse than “no” is a “not yet”

Can change behaviour but hard to change beliefs:

  • don’t believe what you tell them
  • don;t believe what you show them
  • believe what friends tell them
  • people always believe what they tell themselves
  • recognise leadership is scarce – is uncomfortable
  • few things happen by accident
  • don’t settle, have faith in what we do
  • inspire, connect, leverage…

Agile In Government: Successful On-Time Delivery of Software

Adrian Royce delivered this presentation (and the paper won the award for best industry paper):

  • agile buzzword – everybody wants to be flexible
  • chose Scrum – collaboration and for the whole team, encompasses agile principles
  • backlog, only tasks of highest immediate business value were actioned
  • pilot project successful (Housing)
  • twelve successful projects delivered using Scrum (6 = pilot, 3 < pilot, 3 > pilot)
  • largest Scrum project undertaken ($3 million, 4 months ahead of schedule)
  • not everyone ready for Scrum, “just common sense”
  • sense that agile projects increase risk
  • agile = no documentation – government audits require documentation
  • obstacle – organisation and culture
  • benefits – hard to quantify, able to respond quickly
  • increase in morale, productivity, adaptability and business engagement, low staff turnover
  • Scrum Master is essential, focus on team, remove impediments, sprint zero is a necessity
  • do not impose, keep productive teams together, human interaction over technology
  • measure everything, focus on quality (client was not going to be the first to find a bug), leadership essential

Implementing an Enterprise System at Suncorp Using Agile Development

ASWEC 2009 - James Couzens

James Couzens delivered this presentation:

  • what worked well – business engagement, wide stakeholder group
  • not working well – coordination with integration team, managing backlog, overly focussed on showcase
  • definition of done not appearance of done
  • textbook agile does not scale without adjustments
  • business need to be onboard

Keynote: Agile Thinking – From Concept to Reality

Graeme Wood, the founder of Wotif, delivered this keynote:

  • started using agile without knowing they were using it
  • design constrained by six UI screens and a rough database design
  • chaos is fun, makes people think quickly
  • market for hotel rooms not working efficiently (travel agents) – only 60% – 70% occupancy
  • no business plan, no design, originally written by two people sitting side by side, allowed for quick change
  • launched in 2000 with 60 hotels, slim margin
  • no advertising budget, word of mouth, wined and dined journalists, wrote stories, etc
  • simplistic UI – has hardly changed
  • supplier can change cost hour by hour – not locked in
  • fewest number of clicks, no login / registration
  • keen not to have hospitality people – that was model we were trying to change
  • small teams, 9-10 max – largest system made them focus on the architecture – if don’t have that becomes “wild west territory”
  • flat organisational structure, keep small teams focussed on what they are there for
  • business dragged back from solving all of the “distressed inventory” opportunities
  • need to get agile thinking into the business planning area  why don’t more IT people go towards management? – IT such a big part
  • start your own conversation, send a demo to influence, start a future systems blog
  • communication with potential business partners or customers
  • social networking has opened up communication outside normal business
  • all this fails, resign and start your own business
  • majors came aboad reluctantly, no paid positions, alphabetical is star rating, started renaming properties and getting regraded – leveled the playing field
  • suppliers to hospitality industry have been slow to change
  • started with Visual Basic, now all open source
  • Wotnews – public site plus corporate solution to look for customers, staff, etc… Initially around financial services, feeds from the ASX, verging on Media Monitors, greater depth than Google News, can get Wotnews to get competitors newsletters
  • re-architected about two years in, cancelled big bag because it didn’t feel right,now doing incrementally

Static Bug Checking Tools and Why You Should Care

Nathan Keynes delivered this presentation:

  • date back to Lint (1978)
  • FindBugs
  • most people just run once
  • most bug checkers report false positives and false negatives
  • commercial bug checkers expensive, comparisons not available and price on size of codebase
  • upfront effort, legacy codebase may not be parseable
  • Parfait for C++ / C – Sun for Solaris
  • BegBunch – benchmarking bug checking tools – accuracy / performance

Simulating Software Evolution with Varying Numbers of Developers and Validation Using OSS

Steve Counsell delivered this presentation:

  • hard to known optimum number of developers – Brook’s Law
  • used software to simulate this
  • empirical studies difficult – costly, OSS disparate, developers
  • comprehension not so good, implementation very little variation

Project Management Stage

ASWEC 2009 - Project Management Stage

I was thrilled to be invited to chair the Project Management Stage on behalf of the Agile Academy, and introduce two awesome talks by Paul Bannerman (Risk Implications of Software Project Organization Structures) and Steve Jenkins (Failing at Iteration Management – Analyst Style)

ASWEC 2009 - Craig Smith Project Management Stage

ASWEC 2009 - Steve Jenkins

Extreme Programming Stage

Myself and a number of my colleagues were together on this stage including:

Andy Marks presenting Faking Agility – A Coach’s Observations

ASWEC 2009 - Andy Marks

Rebecca Hopkins presenting Infrastructure Projects Go Agile!

ASWEC 2009 - Rebecca Hopkins

And myself and Paul King presenting Experiences from Agile Projects Great & Small

ASWEC 2009 - Craig Smith &amp; Paul King

and the copy of our presentation:

JIRA 4 Partner Hosted Seminar

/ Craig Smith / Leave a comment

In November, Steve Dalton and I hosted a partner seminar for the launch of JIRA 4.0. Steve’s company Refactor is an Atlassian partner and I attended on behalf of the Agile Academy who sponsored the room at Brisbane Square. Atlassian provided a JIRA t-shirt for all of the attendees.

Steve kicked off with an overview of JIRA and a demo of the the new Open Social dashboard as well as the new JQL functionality.

I then gave a demo of JIRA and GreenHopper 4.0, and its usage at Suncorp. Some of the topics I covered included:

  • overview of other new Jira functionality, such as activity streams, the new menu system and the ability to create a new issue on the right hand side of the Find Issues screen
  • GreenHopper is a plugin
  • remember the difference between radiators and refridgerators when evaluating tools
  • Suncorp chose JIRA due to cost and already in use
  • housekeeping – GreenHopper administration (global and local), custom fields (story points, epics), performance
  • planning board – versions and components, new epic functionality, synchronisation, release, drag and drop functionality, statistics, print cards, user preferences and contexts, new card button, new wiki rendering
  • task board – setup, workflows, new Kanban functionality, storypoints, double click cards, subtasks
  • chart board / release board – reliance on statistics and GreenHopper functionality
  • cross project burn down and the new agile gadget

There is no video of the event, although I feel the JIRA 4 webinar covers much of the functionality we discussed quite nicely.

OSDC 2009: Experiences From Agile Projects Great & Small

/ Craig Smith / 1 Comment

My presentation from the OSDC 2009 Conference in Brisbane that I presented with Paul King called “Experiences From Agile Projects Great & Small” is available on SlideShare.

Experiences From Agile Projects Great & Small

Facilitating a Successful Developer Day

/ Craig Smith / 3 Comments

When an executive manager approached me a few weeks ago with the idea of running a developer day with one of his Java development teams, I jumped at the opportunity. The idea was simple: emulate the success of Google 20% time and the Atlassian Fedex day to improve the collaboration and skills of a bunch of developers.

Research

I started out with some research and found the following excellent resources:

The Running Sheet

It was decided (in hindsight, a fantastic decision) to hold the day in a neutral venue away from the usual office in a training room environment. The pre-requisites equipment-wise were at least one machine per two attendees (we ended up with two high-spec developer machines and a bunch of laptops), network access, a projector and the usual agile materials of post-it notes and pens. A supply of snacks and drinks was also available to give it a “start-up” feel.

As we had two days and wanted to also allow for some presentations and discussions, the run of the days ended up as follows:

Day 1

9.00am: Standup Introductions (All), why are we here, team building exercise (paper folding exercise)

Give each member of the group an A4 piece of paper, the facilitator needs one too. Have them close their eyes. The facilitator issues the instructions and follows them as well. No questions are allowed.

  1. Fold the paper in half.
  2. Rip offf a corner
  3. Fold the paper in half
  4. Rip off a corner
  5. Fold the paper in half
  6. Rip off a corner

The group can now open their eyes and find that there are many different shapes of paper. The debrief covers the need for two way communication and that the different perceptions of the people caused the many different designs. If time permits the group can be put in pairs. Have the pairs sit back to back and repeat the exercise using two way communications and find that the patterns come out closer

10.00am: Presentation (Agile Tools & Maturity)

11.00am: Brainstorm / Retrospective: What would make this a better team -> how can we make a difference in 24 (8) hours

The idea was to review the good and not so good of the team and help determine the issues the team would like to tackle.

12.30pm: Iteration 0 / Planning / Lunch

Melbourne GI Developer Day Rules

2.00pm: Iteration 1

Including a quick planning session

3.30pm: Iteration 2

Including a quick retrospective and planning session

Day 2

9.00am: Standup

Overview of highlight of yesterday and what planned to do today.

9.30am: Iteration 3

Including a quick retrospective and planning session

10.30am Iteration 4

Including a quick retrospective and planning session

12.30pm: Developer Practices discussion / lunch

Based on the development practices prescribed on the Donkey open source project.

1.30pm: Iteration 5

Including a quick retrospective and planning session to ensure ready for the 3pm demo

3.00pm: Demo Showcase

Melbourne GI Developer Day Demo

4.00pm: Closing Statements and circle

The Outcome

Well, it turned out better than I could have imagined! Iteration 0 everybody turned a bunch of PC’s in boxes and chairs and tables into 5 distinct teams. Story walls went up, planning started and the software required was downloaded (or people remotely accessed their work machines). Pair programming naturally happened (the limited number of machines helped this) and teams supported other teams when they ran into problems or needed assistance.

Melbourne GI Developer Day

The 5 teams focussed either on stuff they wanted to learn or things they wanted to achieve to help their everyday work. The projects attempted roughly consisted of:

  • a mobile web application using the Play framework
  • investigation into using JMX for application monitoring
  • automating WebSphere environment creation with JACL / Jython scripts
  • scripting legacy mainframe account creation for testing purposes
  • performance testing using JMeter and The Grinder

The morale was high at the end of the two days, everybody clearly learnt something and the developers were asking when the next event was. Success!

Dave Thomas on Maximum Software Productivity – Breaking The Rules!

/ Craig Smith / Leave a comment

Dave Thomas paid a visit to Brisbane to present his talk Maximum Software Productivity – Breaking The Rules! at the Microsoft office at Waterfront Place. He set the scene by suggesting the last time he gave this talk he was innundated with hate mail from agilista and objectas! Dave promised the slides would be posted, but I have not been able to locate them if they have. Here are my notes from the session:

  • tired of need to get agile and need to get objects – both good, but got nothing from it, where is the value?
  • objects good, agile good, but are we any better off?
  • most software late, bloated, poor to maintain
  • business does not define requirements well, don’t engage or talk to the customers (NEHITO visits – “Nothing Ever Happens In The Office”), insist on the industry norms because that is what everybody else is using
  • storypoints – training wheels for people who don’t know how to estimate
  • IT does not estimate well, do not build continuously or automatically test (need to be prepared to write a big cheque), also fixed in technology
  • if not ready to do TDD, just stop! Scrum will only make you feel good
  • need to change the rules to be competitive
  • living in legacy due to OO mud ball – legacy is code where there is no tests (see Brian Foote – Big Ball Of Mud)
  • objects too hard for normal people, first thing to be voted off the island should be Hibernate, objects don’t work for lots of things (queries, rules, transformations, etc…)
  • 80% of objects are CRUD – no objects except for the junk in the middle – just data, no simulations or data model – taking a solution and making it complicated and slowing it down
  • frameworks – so many to choose from, new versions, latest things, lots of dependencies
  • dependency injection is proof of how much we have screwed up objects
  • object libraries are unstable and languages are complex (attributes, generics, concurrency)
  • very few people use interfaces properly and keep them stable release to release
  • little reuse – promise not a reality
  • serialization carries all of the baggage of the objects contained within
  • objects suck up performance and memory – bulky and computationally expensive
  • objects cumbersome and slow for multi-core processors to run efficiently
  • objects are sequential and parallel
  • Java application will be 4 to 5 times slower than PHP, because objects are slower
  • can we shorten software value chain – shorter, faster, cheaper – Facebook built in PHP but the money rolls in
  • agile shows predictability and productivity but zip about quality
  • agility is good, but in Java it is very difficult to change the code quickly
  • scrum increases morale (everybody feels better), but makes no difference to quality unless doing TDD
  • lean thinking – software waste – if not prepared to spend $2 million to do continuous integration and TDD then they are not serious about their software output and quality
  • don’t go to meetings unless it is increasing the bottom line – will it help ship code?
  • how to make zero defect code? Don’t ship anything!
  • lean – simple – why am I doing this? – do we need a new framework? – NO!
  • staff a team with people who have shipped software (have a track record)
  • fix price your consultants and enforce that they make delivery with acceptance tests – pay when they pass
  • reward people on delivery, not how long they work
  • tangible requirements – story on the front, acceptance criteria on the back, start with acceptance tests, they are more valuable
  • envisioning – what the developer sees is not what the customer wants
  • agile great for prototyping – building small requirements on the fly
  • a backlog filled with lumpy requirements will burn out designers and product owners – original Scrum paper said sprint 0 should be 3 months – envisioning
  • architects – not a job, a role – should be able to code
  • some companies pay senior developers same as VP
  • extreme design – four hours to design software and hardware and cost it – after a few, you can get close and find out quickly what you don’t understand
  • serious engineering needs design
  • API first – design the architecture, should always be able to get architecture from the code (push a button)
  • need API’s versioned in the code
  • want to close gap between needs and solution
  • a picture is 1,000 words, a table 200 and a diagram 50
  • table driven programming – easily understood, easy to refactor, easy to consistency check (look for missing data), easy to version and diff (just data), data driven can be changed live in a running instance
  • integration – talk to old systems use RSS/ATOM feed (almost all old systems will give a feed for each transation) then you can talk it without custom api’s, REST/JSON your services or use ODBC as a simple interface (its not just for databases), use mashup tools to deliver an integrated application view
  • use scripts to save time & dollars – most software gets thrown way even before turned on, C# and Java too heavyweight, Ruby, Python, PHP, Groovy, Clojure, can easily leverage cloud services and existing services
  • productive languages – LINQ and Reactive LINQ (Haskell underneath), Erlang (good for swicthing and moving traffic, highly efficient), F#, Ruby, Scala (a better Java), Kleisli (bioinformatics), Clojure
  • Everybody should read “The Wizard Book”, Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman
  • hardware is cheap, cloud is cheaper – all interesting data is in memory, databases are just journals and don’t really exist, Google does everything by brute force search (eg. translation), speed now means complicated stuff can be done easier and cheaper
  • data driven – massive storage means we can store it all very cheaply, run smart algorithms to determine best value customers because we have all of the data, recommendation engines (NetFlix), Net Promoter, complex event processing (open intelligence), real time financials (no end of month financials, know state of company all of the time)
  • query oriented programming (QOP), Greenplum, Q, Aleri (basically extended SQL dialects with functions) and other functional languages
  • array VM’s – better than object VM’s – always boxed, simpler garbage collection, support all data types (array of stuff is an array of stuff), VM can be small (just an interpreter), arrays are column stores already and trivially serialised, take less space and programs concise and compact
  • best practices for functional programming – agile , refactoring tools, FindBugs / Lint
  • challenges for functional programming – get out of math phobia, different way of thinking, need to write literate and understandable code, think in functions
  • yesterday and tomorrow is always wrong – if you get more bang for buck and competitive advantage, why use existing technologies, if you believe IT is strategic you need to do something strategic with it and dare to be different
  • lost of old things work, lots of new things work well, get out of agile and OO box