FrAgile Development

On June 12th I gave a lightning talk on FrAgile Development at Skills Matter in London, you can watch the video here. It was by far the most controversial talk I have given to date. Before I instantly get flamed by Agile fans the talk was not to criticise the methodology, but was a play on words and/or what can start to happen if things go wrong. The best part about the talk was the range of reactions that the audience took from the talk, which I will summarise at the end.

For the purpose of this post the FrAgile Developer writes in red, the voice of some reason will be in blue. Imagine them as an angel and a devil sat on the developers shoulder.

The slides went through some bad practices that I've seen (and participated in whilst learning and not knowing any better). During research it seems others have also thought of Fragile development as a concept and c2.com was a great reference point.

Ctrl CV Design Pattern

Refactoring is expensive, and copy paste is the quickest possible way to reuse code without impacting something thats working fine. You don't need to retest what was done before, and if there's a test why not copy and rename that too. The junior developer might be tempted or even guided to do this, and I've seen things like this in front office and UI development. The point of this was to suggest that the laziest solution is generally not good for the product or maintenance in the long term.

Extend Everything

At university you learn about these object things and extending them. Sounds good, so let's extend everything that means we will be able to use that useful method in this other class. This often leads to Spaghetti like code, where everything becomes tightly coupled together. Changing one part of the system can have an adverse impact on a completely different part. Thinking about composition as well as inheritance is an important lesson to learn early, ensuring that a class only actions the intended behaviour and is kept as orthogonal as possible.

Ignorance Driven Development

We don't have a product owner who is willing to be accountable for guiding the product, and they're never going to know what they want until they see it. Ok let's build something that we think they'll want and see how we go. This is often a sign of an organisational issue and though this can be a successful approach you can end up spending a lot of iterations on prototyping complex systems to find that functionality at the heart of it is really wrong. Tying down the basic requirement, even if just the initial scope should be the goal otherwise you risk a never ending sprint or product iteration.

Rabid Prototyping

Dude we've got this really complicated problem where we need to write a highly complicated algorithm to solve it. I've been working for the last 8 hours and I've come up with this sophisticated algorithm to return a single timestamp. As developers we can often be tempted to dive down a single path rapidly throwing stuff together and over complicating problems. Often the key is taking a step back or considering the options in a pair. In this case where a huge algorithm is written, it could have been simpler and made more sense to refactor to a different data structure, for example.

The Burnout Chart

How many hours have your worked this week? I'm up to 120 hours!
At the end of the day that's not a sustainable.
My day never ends, so it doesn't count!
This is a cultural issue that can be costly across a company. Things like this effectively bully developers into staying late and doing working longer or harder than they are comfortable with. In this kind of environment it's a race to who burns out or breaks down first.

Heart Break Pairing

This relates to either when a pair breaks up, or where someone is a lone wolf developer. In the break up case it makes more sense for the pair to take some cooling off time rather than arguing across the shop floor. In the imaginary friend case it's really difficult, as no one is actually available to pair or code review.

Potential Solution

After the above, without good guidance, there are many ruts developers both junior and seasoned can fall into. How can we avoid it? If you're based in London you can look to improve your skills by considering your career as a craft where you take pride in the solutions you build and deliver. The LSCC (London Software Craftsmanship Community) and the LJC (London Java Community) provide excellent platforms for this.

If you're not local to a large community group there are some excellent books that can get you started, for example The Well Grounded Java Developer is an excellent starting point. Work with your team and more experienced developers to learn from them and improve. This is by far one of the best ways to learn and improve.

The feedback from the talk was really positive and a range of people took different things from it. Some thought that methodologies are too ideal, and not indicative of the real world. I fear this is probably true for many developers, and bad habits come as a given practice. Others had seen problems like this themselves in different teams over the years, and could look back on these experiences and have a good chuckle. Others were interested in how they could improve and went away looking for books and resources to do so.

Our 3 Planned Talks for Java One

Having written about my career history and how I came to be speaking at Java One, I thought it would be useful to briefly outline what the three talks are and what we hope people will get from attending them.

Community Driving the Future of Java: Adopt a JSR - BOF4540

This BOF is an open discussion on the Adopt a JSR program, which aims at encouraging Java Community members to get involved with Java Specification Requests. We are going to highlight our journey through from starting with a lightning talk right through to working with Stephen Colebourne to help validate the design of JSR-310. We will do a small introduction on what we have worked on to set the scene and then the main focus of this talk is to discuss what people think about the Adopt a JSR and if there is more we could potentially be doing to help move this initiative forwards. If you're planning on coming along to the event, I'd recommend that you take a look at the following first to get the most out of it:

• Adopt a JSR homepage on Java.net
• 310 Adopt a JSR homepage

The event can be attended by Java developers of any level, and it would be specifically useful for members of other JUGs working on Adopt a JSR to come along to the BOF. We are hoping to have other senior LJC members in the audience with a wealth of experience when it comes to Adopt a JSR. For specific JSR-310 discussion the follow on session below will be useful too.

JSR 310: What’s Taking So Long? - BOF5127

Following on from our BOF on Adopt a JSR this BOF is on the work we have contributed to the design and testing of JSR-310 and the ThreeTen project. We want to use this session to explain and work with delegates on the complexity of developing an API that is capable of ISO-standard calendar systems, whilst making it extendable to support more complex calendar systems. It will be a great opportunity for us to dig under the covers of the new API and explain some of the decisions made. We will be joined by Roger Riggs of Oracle and we are hoping Stephen Colebourne will be along to join in the discussion. This talk is suitable for Java developers of any level who want to know more about how JSR-310 will change the way we work with dates in Java.

To get the most out of this session the following would be good pre reading materials:

• About a new date time API
• Lightning talk introduction
• ThreeTen Documentation (JavaDoc very useful at this stage)
• ThreeTen on GitHub

London Java Community: How to change the world - CONF5130

The final talk we have had accepted is based on our experiences of working as a group of developers contributing to the Java Community Process. The London Java community has more than 2000 developers and is rapidly growing, all with their own (frequently differing) opinions and ideas. Our aim has been to provide a single voice for many developers and has had many challenges along the way, but also some successes. This conference session will give you direct access to a panel of developers that have been working for the London Java Community in this capacity:

• Ben Evans
• Jim Gough
• Richard Warburton
• Trisha Gee

Come along and find out what we have been working on, what problems we have faced and how we have worked to gain success. Hopefully you will get the answer to "Is it worth it?".

Journey to Speaking at Java One 2012

Late Thursday night I received some fantastic news that Oracle had accepted 3 of my 4 submitted talks for JavaOne 2012. For me this is a milestone in my career and has been thanks to many people in the community over the past 5 years. This blog post is going to be a short tour through the last 5 years of my career, thanking certain key people along the way who have helped me to this landmark achievement.

In 2007 I graduated the University of Warwick and moved to London with a job ready to start in September. The toolbox was armed with a very broad range of practical and theoretical skills from my MEng Computer Science degree. At this stage of a graduate's career they are eager to dive right in and write as much production code as possible, I was no different. I was lucky enough to have a manager who was able to point out the craft of Software Development and how design and consideration of building products would have a significant impact in my long term career. These one hour meetings in the pub were the most valuable meetings I could have had. 

I wanted to learn more and looked for online resources. The first thing I picked up that September was a Podcast called The Java Posse - still going today and definitely worth a listen for developers of all levels. JUGs (Java User Groups) were mentioned, and I took a look to see if there was one in London and at this point was shocked that there wasn't an official or unofficial JUG I could find. As I was about to move to New York I didn't follow up on this further, continued to listen to my podcasts and built on learning to build scalable and maintainable systems within investment banks for the next 2 years.

Sometime towards the middle of 2009 I met a contractor who was active in the Java Community, he mentioned the London Java Community and another Java Community based in London. Little did I know that when I looked in September 2007, Barry Cranford a few months later had formed the London Java Community. My initial response to a recruiter running a community was apprehensive, then in late 2009 I attended my first event The Unconference and this changed everything.

I met Barry and realised this wasn't the same breed as the recruiters who phoned me up on a daily basis. It was a normal guy, a little nervous about speaking to many developers (not that you would know this now) and had worked tirelessly with friends in the community to arrange the conference. The diversity in the community right from the beginning was top of the game, everyone was welcome irrespective of background. I felt right at home, people talking about Java on a Saturday - this was amazing. Barry is to thank for starting one of the most active and successful JUGs. 

I suddenly recognised a familiar face, after a few gulps of coffee I realised it was a someone who had given me one of the most technical grillings I have ever received to date! When I say grilling I mean pushed me in an interview to bring the best out of my technical ability, and thankfully it was a successful interview. Ben Evans is one of the Java kings in London and has pushed me both technically and to contribute to the community ever since, informally a great mentor and a fantastic friend. I also met at the same time Martijn Verburg who has one of the best insights into best practices and strong development skills across the community. My work with Martijn was further in the future with the LJC JCP, and he too has been a great mentor and contributor to us making Java One.

My JUG membership for the next year was somewhat of a social one, working to greet and connect people in the community and helping to facilitate the running of the events with the LJC associates. Whilst this was fun I was looking for something that would get me more involved in the community and ultimately give me a platform to start speaking to larger audiences about Java technology and the surrounding ecosystem.

In July 2011 I started working with LJC JCP, and specifically helping to design the framework for adopting a JSR in the community. The targeted JSR was JSR-310, as Stephen Colebourne was based in the UK it made it easier for us to establish relationships. Initially as with all JSRs the main challenge is explaining the concept to other developers to maximize the input from community members. Later in 2011 I met Richard Warburton who has helped add some real power behind our Adopt a JSR efforts. The work we have done with the community and the efforts here will make up the main body of our talks for Java One. Although I had publicly spoken before, these were the first talks on Java with the community and these were well received. Following on from this we have also worked on helping with the TCK and helping validate the redesign of the API.

I'd like to thank all the people mentioned in this blog post and those that are not mentioned that have helped out along the way too, over 5 years and a short post I'm sure I have missed some people. For people who are looking to get involved in conference speaking or getting more involved and improving their Java skills I'd highly recommend working with people in your local Java User Group, as many of us in the London Java Community can testify anything is possible. Looking back on what I was thinking in 2007 I never thought the first time I was at Java One would be when I was speaking there!