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.