Tracks

Bob Martin recently published a book called "Clean Code", in which he writes "Consider this book a description of the 'Object Mentor School of Clean Code'". Perhaps, like me, you have wondered about what other schools of coding practice there are? Whether there is a difference between clean code and beautiful code? I bet you haven't. I bet what you are wondering is whether this is remotely relevant to your daily business of producing working code in an acceptable timeframe. Your real worry is whether you'll be able to implement any functionality at all without screwing up and breaking something else!

The majority of software work involves maintaining and extending existing systems, very few of which are a joy to work with, and even fewer adhere to Bob Martin's style guide. My contention is that if legacy code is your reality, then code cleanliness should be top of your agenda. As Mike Hill once put it, if you're digging yourself into a pit, the first thing to do to improve matters is to stop digging.

Although I think most programmers recognize clean code when they see it, unfortunately it doesn't follow that they are capable of producing it. In this talk I will take a look at some concrete techniques for improving the design of your code, and developing your "code sense". Oh, and in case you were actually wondering, firstly, of course there is more than one school, and secondly, I think "beautiful" is optional, but "clean" shouldn't be.

Software development contains many day to day practices. One more effective than the other. In this talk Ola focuses on the practices that looks good but are in fact anti-patterns. He talks about build machines, co-located teams and ineffective meetings.

A handfull of anti-patterns are brought up and described. How to spot early symptoms and how to remedy the situation.

Elicit utvecklar kundanpassad mjukvara inom framför allt administrativa stödsystem, och arbetar sedan flera år enligt en egenutvecklad Lean-baserad metod. Ta del av erfarenheter kring hur Lean används för att få ut bästa effekt ur IT-företagets alla dicipliner.

• Agile-metoder och verktyg för att hålla kundfokus i leveranserna - så fungerar det i praktiken.
• Kommunikation är nyckeln - bra kommunikation är bättre än dålig kommunikation, naturligtvis. Men, vad är bra kommunikation?
• Se helheten. Det enskilda projektets förhållande till andra projekt, drift, förändringsbehov, avvikelsehantering m.m. Lean-principer för att få ut bästa effekt av ITIL.

In this session we will take a look at failure modes for a Scrum implementation. Failure modes for Scrum Master, Team, Product Owner and Management will be discussed. There will also be discussions about failure modes in sprintplanning, daily Scrum, and sprintreview. Finally we will take a look at how to approach failure modes.

It turns out that ancient philosophers knew a lot about software - did you know that Plato defined object-oriented programming? This session applies old lessons to new problems and old problems to new lessons. Galileo already figured out everything you need to know about SOA. This talk explores the software development world today, spanning technologies, methodologies, the 2nd wave of outsourcing (the rise of Chindia), and pretty much every topic under the sun with an even remote connection to software development in the 3rd century BC and the 21st century AD.

In this talk I discuss how developers and managers deal with the problems encountered in traditional "enterprise" development. It turns out that most common sense has leaked out of these discussions; I hope to plug the hole. The idea behind this talk is to use ancient philosophers as a departure point to talk about all the things that are broken in the development world today.

Little or no code, but issues that developers face on a daily basis, and some solutions to flawed thinking and attitudes.

Great developers know that writing code is a much smaller and easier task than understanding and modifying code is. Therefore, they make sure that the code they write is easy to understand and that future extensions to it can be done without having to go back and rewrite old functions. When implementing a new feature and facing ugly existing code, they do not simply add to the mess. Instead they first do a little cleanup to make it easier to add the new feature.

A good developer might be a lightning fast coder and very competent at solving problems. Even so, if the code is not easily maintainable it will result in reduced productivity over time. If we could only teach them refactoring, design patterns, test-driven development and DDD. If only they would care like we do...

We are doing it wrong! Instead of trying to teach techniques, we should focus on creating awareness. We must first inspire our colleagues to want to learn before we can teach them. In this presentation I will expand on this, and talk about some ways that we can use to achieve interest in moving from good to great.

How do you figure out where to start with XP/Agile practices ? How to tell which practices should be used together, which can be safely set aside to begin with ? How to predict the consequences, good and bad, of changing your software development processes?

These questions often confront managers new to XP or Agile processes. It turns out that there is a methodic and rigorous way of dealing with them: arising from the discipline known as "Systems Thinking", the use of Diagrams of Effects or Causal Loop Diagrams to understand the dynamics of software projects has, by now, become a standard tool in effective XP/Agile coaching.

This session introduces the notation and the modeling activity, then offers participant a chance to consolidate their learning by actually practicing DOEs.

Many people and many organizations try to get their head around agile software development, but some things are just unintuitive.

How can releasing often not be an increased cost? There are all sorts of things that needs to be done when releasing, so it just have to be a waste of time? How can rework due to change of requirements be a positive thing? The real problem is the fuzzy requirements, and now agilists claim we should solve the symptom instead of the problem? And pair-programming? Come on! Paying two people to do the job of person job?

This talk will dig into why the unintuitive parts of agile actually work and why they are important cornerstones of the agile puzzle. If you think that agile feels a bit strange or if want to understand the fears that others in your organization have when you talk about agile and how you address them, this talk is for you.

One of the most popular buzzwords in software development is agile. Today everyone wants to be agile. That is good! However, being agile is not enough. The most important character you need to have to be a great software developer is to be smart. What does that mean? Most people know intuitively what "being smart" means in everyday language, but what does it mean for software. In this session, Agneta Jacobson will describe what it means to be smart when it comes to developing software from requirements through to deployment. And being smart is more than being agile!

Unit testing is becoming quite common, Test-Driven Development is definitely increasing and nowadays you can even hear people talk about Behaviour-Driven Development when you enter large companies. These are all positive things, but yet, many organizations struggle.

The most common complain we hear is that the test suites are brittle. Even minor changes breaks a lot of tests and the amount of work needed to fix them is too much. This leads to situations where tests are left red and after a while, entire blocks of tests are turned off. The tests basically don't seem to even carry their own weight, let alone are the productivity gains they were supposed to be.

But don't give up! There are ways to do TDD that will give you the productivity gains you were promised, with test suites that are not heavy burdens but are instead your main point of focus and also a brilliant safety net, test suites that are much less brittle, more maintainable *and* more readable. Any skill takes going through some stages to master, and problems like this only indicate that there are a few more things to learn. This talk aims to be the starting point on your journey to become a black-belt test-driven developer.

Technical debt is a term often used for work to be done in the code, typically undone refactorings. As the code-base grows, unattended technical debt grows with an interest as problems start depending on one another, making it ever harder to do the right thing. Eventually, it is impossible to perform relevant design improvements within a single iteration. "Refactoring paralysis" has occurred. Daniel Brolund and Ola Ellnestam will present a light-weight, yet effective, approach used to visualize, plan and perform the needed refactorings over several iterations, without ever having a broken code-base in the process.

The adoption rate and associated success stories around Agile practices are at an all time high. In the early days of Agile, it was often applied to projects which were smaller in scope and typically consisted of co-located teams. Today, the picture has changed significantly. As companies look to scale agile to the enterprise level they also begin to deal with new agile complexities such as globally distributed development, growing team size along with numerous organizational complexities. This session will look at the challenges of Agile @ Scale, introduce a set of core Practices which provide a foundation for scaling Agile, as well as various new solutions from IBM Rational optimized for scaling agile teams.

When you were hired by your current employer, you may think it's because of your winning personality, your dazzling smile, or your encyclopedic knowledge of (insert technology here). But it's not. You were hired for your ability to sit and concentrate for long periods of time to solve problems, then placed in an environment where it's utterly impossible to do that! Who decides that, despite overwhelming evidence that it's bad for productivity and people hate it, that you must sit in a cubicle? The furniture police! This presentation describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to gird yourself against all those distractions. I talk about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the mid-guided attempts to sap your ability to produce good work. And I give you ways to go on the lam from the furniture police and ammunition to fight back!

How far does Agile scale? Multi-team, multi-site Agile projects are no big problem. But how far can you go? What happens when agile practices start hitting the boundaries of corporate culture? This talk looks at the reasons behind the organisational impediments to Agile development, and offers ways of resolving them.