Jazoon 2013 – How To Do Kick-Ass Software Development

24. October, 2013

Jazoon 2013 badgeOne of the most important aspects of agile is to notice your problems and solve them. How? A good strategy is to look what others did. In “How To Do Kick-Ass Software Development,” Sven Peters shares his experience with “Kick-Ass Software Development at Atlassian” (slides on slideshare, video on vimeo). Yes, he have the talk wearing the “Kick-Ass Super Hero Costume“.

A short refresher what agile aims to be (slide 12):

  • better software
  • less overhead
  • faster development
  • happy customer
  • happy developers

This only works when you continuously improve. Legacy teams, can you hear me?

Kick-Ass Software

But before we can start: How do we know we build the right thing? Bad example: The Microsoft Kin. Never heard of it? They sunk about $1 billion in the project. Makes you wonder how you could miss it, right? (slide 25)

Better solution: Fake it. IBM made extensive experiments with a state-of-the-art speech-to-text system before starting development. How did they do it? They hired an extremely fast typist who remote-controlled word. Cost? Negligible. Result? Text-to-speech won’t sell – people can’t edit the text fast enough using words, they are hoarse after eight hours and the whole thing really breaks down in an open office space. (slide 27)

Use paper prototypes. Something geeks eventually forget: You can drag a piece of paper over a (wooden) desktop just like a window over a screen. (slide 28)

Quick and easy feedback: Easy to find, simple, fast to submit (slide 32). Customers love it! But remember to protect your developers. Gmail uses the “Sh*t umbrella” (slide 38). But not everyone is Google. Put each developer into a support seat once in a while. Not only can they solve problems much more quickly, they also learn to look at their work from the customer perspective (slide 42).

Kick-Ass Team

In most companies, there are way more developers than testers. Atlassian has a ratio of about 13:1. This creates bottlenecks and issues with accountability and scalability (slide 46).

Solutions: Dev X tests features of other devs. (slide 49)

Use “DoTing” – Developers on Test (slides 50 -56):

  • Give developers the same training QA receives
  • Pair testers with devs
  • “Blitz Test” – Once in a while, invite everyone in the company to try the product
  • Use test recipes
  • Split sessions (1 dev and 1 QA test the same feature independently)
  • Bug Hunter (have someone try really hard to break the app)

Remember “Quality is everybody’s responsibility.” (slide 57)

At the Jazoon, the slides about design were skipped due to time constraints.

Again: Department barriers slow you down. Work together as one team! Keep improving! (slide 69, see also: WIKISPEED in “Test First Saves The World”)

Kick-Ass Collaboration

The lonesome cowboy coder is a relic but teams always mean trouble. Interesting video of a heavy-traffic crossing without signals on slide 73. “Traffic Rules protect us from accidents” -> “Development Rules are protecting us from making mistakes”. Like we need a concurrency library in our preferred language, we need a “Fast + Simple Workflow For Parallel Coding.” Otherwise we will be slow and some people will enable their “god mode.” (slide 77)

DVCS make this simple. Create a branch for every task (slide 78). They should have short lives (2 days).

“Pull Requests can improve your code quality” (slide 80). This helps to spread knowledge. But keep an eye on the blame game!

Everyone in the same room would be great but it’s not always possible: People travel. You really want to pull some experts two weeks out of his family? (slide 85) Ask yourself: “Where do I work best?” The answer often is: It depends (slide 86). Make sure people can stay in the zone when they have to.

Make sure you can communicate effectively (slide 87). Emails look great (slide 88) but they cause problems (slide 90). Try chat. Invent your own Portal Device.

Most importantly: Remove friction!

Kick-Ass Automation

Developers automate everything for everyone else. Spend some time each week to automate a menial/manual task for them (slide 101).

4 steps to tame monster builds (slide 104-110):

  1. Instead of having everyone build everything, pass the artifact
  2. Run your tests in parallel. They are independent of each other as they should be, right?
  3. Have a build strategy. How often do you build what part?
  4. Make your stats visible. Use wallboards, information rediators.

Automatically disable flacky tests (113). Use SonarQube and similar tools to detect problematic code. Use Freud to find your own anti-patterns (115).

Finally

Remember managers are also humans (123).

Share stories of success and failure (124).

Remember: To be awesome, you have to step out of your comfort zone (126)

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – User Storytelling: The Lost Art of User Stories

24. October, 2013

Jazoon 2013 badgeIn her talk “User Storytelling: The Lost Art of User Stories“, Ulrika Park (blog, slides on slideshare) made a case to become aware of the spreading practice of “snapshot user stories.” As an example compare “give warrant to use the bonus” (slide 14)  to slide 16:

Elisabeth sees in the MyStore newsletter that she this month has got 12€ in bonus and that she has a total of 16,7€ in bonus on her club card.
E’s husband Claes go to the store. He has a club card too. “You can probably pay with your card” says E.

Claes shops. When he will pays, no bonus is withdrawn from the sum at the cashier.
So he pays the whole sum and gets home. “Strange why can’t I pay with the bonus, how does this work”

E already has a registered user on mystore.se Sometimes she logs in to see her credit card balance.

E logs in and see the saldo “16,7€”. She clicks the balance and enters “events page”

There she sees that she’s bonus owner and that her co-bonuxcollector is Claes.

She gets information that she needs to sign warrant for him and choose the option to print a form.

She choose to print the form, checks Claes, signs the form and goes to the mailbox the day after.

2 weeks later she gets a letter from MyStore that confirms the warrant is verified. A week later Claes goes shopping. This time, the bonus is withdrawn from the total buy.

I think even without the highlighted parts, you can quickly see that the whole story is much richer than the “more efficient snapshots.” Moreover, it helped to expose some critical problems that no one noticed before:

  • Hidden expectations (user must already be registered)
  • This process takes four weeks! Do we really want that?
  • It helps more people. QA will be able to derive test cases from this. Developers will know much better what is expected from them. BAs will know which questions to ask.
  • It’s pretty easy to follow it, even if you’re not a software developer. Remember that these stories were meant as a means to communicate better with customer and managers?

A good story has these properties:

  • A hero
  • A platform
  • An enemy or challenge
  • Emotions (“how does this work?”)
  • Allies (cashier, web site)
  • A mission to accomplish

Everything is held together by a logical sequence of events.

Related articles:

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – Big Data beyond Hadoop – How to integrate ALL your Data

24. October, 2013

Jazoon 2013 badgeBig Data is being used everywhere. Kai Wähner mentioned a couple of examples in his talk “Big Data beyond Hadoop – How to integrate ALL your Data” (slides on slideshare):

Anyone else getting worried by these “success stories”? How do you feel as a mobile customer that your mobile company tries to prevent you from leaving? How about using Big Data to notice bad customer service and prevent making customers unhappy? How do Macy’s competitors feel about this “monitoring”?

Anyway …

One great point was “Silence the HiPPOs” (highest-paid person’s opinion). With the ability “to interpret unimaginable large data stream, the gut feeling is no longer justified!”

Why Big Data? 3 V’s: Volume, Velocity, Variety. But don’t forget the fourth: Value (slide 8)

Before you can start analysis, you need to get the data from somewhere. That usually means integration of a foreign system (reading the data), manipulation of the data (like string to int or date conversion, etc.) and filtering (duplicates, importance, …). See slide 9.

Beware that Big Data is no silver bullet. If you have a gigantic amount of data with poor quality, that will just give you huge problems.

When planning for a Big Data project, begin with a business opportunity (slide 22). Chose the right data (don’t just import everything because you might need it), combine different sources and use easy tooling (slide 26).

Be wary of ETL tools. The network will quickly become your bottleneck.

For the actual implementation, he suggested to look at Apache Camel (slide 34) as a pure integration framework and the talend Open Studio (slide 56) as an example of an integration suite.

1 Comment | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Visibility Shift in Distributed Teams

24. October, 2013

Jazoon 2013 badgeLike many agile tools, distributed teams make problems more visible. Pawel Wrzeszcz listed a couple of those in his talk “Visibility Shift in Distributed Teams” (slides on slideshare) and gave ideas for solutions.

One of the first issues will probably be trust. If “working at home” is believed to be equivalent to “spends add time on Facebook”, you have a trust issue. Managers worry that their “underlings” stop working as soon as they are out of sight, colleagues worry that they have to do all the work for the slackers. You have a “value vs presence” conflict.

Value here means “value for the customer” – how do they profit from what the team members do? Presence is about control. A need for surveillance is always rooted in distrust.

The solution here is to make progress visible: There should be a central place where you can see who works on what and what their progress is. You can have a web site that lists any changes made to the project sources – most DVCS give you this for free. Set up CI and use public backlogs to track progress. If everything else fails, you can send an email with daily status updates. Have meetings where people focus on what they have achieved and what keeps them from reaching their goals.

“Value delivered” should be king.

The next challenge is usually communication. During face to face, about 55% of all information is conveyed nonverbal. Tone makes up 38%, the words alone count for a mere 7%. In other words, if the text in this post lacks 93% of the information you would get if I explained the same to you in a personal meeting (source).

This why you must have a video conferencing system of some kind. It’s not nice-to-have; lacking one is like sabotaging the project.

Also be aware of the effectivenes of your communication channels. Tune narrow channels.

Use video conferences for daily standup (short, personal), chat for discussions (longer, open ended, needs transcription, not very formal), phone calls (complicated, personal, urgent), face-to-face (important). If you have a distributed team, make sure they meet face to face once per month. Flying them in might be expensive but not doing this might ruin your chance of success.

Be more personal in video conferences. Pawel mentioned the “4th question” to form bonds: Which book did you read lately? How do you exercise? This is the social glue that you need when you don’t work in one place.

Use retrospectives regularly to identify important problems that the team wants to solve.

Related articles:

Leave a Comment » | Conference, Software | Tagged: , , , , | Permalink
Posted by digulla

Jazoon 2013 – True Git: The Great Migration

24. October, 2013

Jazoon 2013 badgeStefan Saasen told the tale how Atlassian migrated from SVN to Git in his talk “True Git: The Great Migration.” (slides on slideshare)

Atlassian has resources on their website if you want to know more about Git and how to implement your own workflow using it.

Key points from the talk:

  • Branching and merging are first class concepts in Git (unlike Subversion, where they were added as an afterthought)
  • Especially the merging support in Git is much, much better
  • You can use clever tools like bisect to zoom in on bugs
  • History rewriting allows to clean up mistakes
  • Adoption for Git is on the rise. In 2015, most companies and projects will have migrated to Git or another DVCS
  • Use a centralized repo for your enterprise – all the processes and tools will be much easier/happier
  • Make sure you have defined a clear workflow and your developers know about it

Leave a Comment » | Conference, Software | Tagged: , , | Permalink
Posted by digulla

Jazoon 2013 – Spring Framework 4.0 – The Next Generation

24. October, 2013

Jazoon 2013 badgeIn his talk “Spring Framework 4.0 – The Next Generation,” Sam Brannen gave an overview of the new features of Spring 4.0 (slides on slideshare).

Spring, which has moved to http://spring.io/, is going to version 4 which means they add support for Java SE 8 and Java EE 7.

As a Spring developer, this means better Groovy support, being able to use lambda expressions and method references in Spring callbacks, support for “JSR-310 Date-Time types for data binding & formatting, a new @Conditional mechanism for bean definitions, & a new WebSocket endpoint model.”

Things that I took home from this talk:

  • Spring Boot is a new project to make it easier to set up “Spring-powered, production-grade applications and services with absolute minimum fuss.”
  • @Lazy is now supported to annotate the place where a bean is injected (formerly, you could only use it to make it lazy at the definition)
  • There is a new API for messaging with support for WebSockets. In this context, you may want to have a look at stomp “the Simple (or Streaming) Text Orientated Messaging Protocol.”.
  • Spring 4 supports Java EE 6 through 7 and SE 6 through 8
  • Repeatable annotations will make code more compact

The slides should appear soon on slideshare/sbrannen.

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Spock: boldly go where no test has gone before

24. October, 2013

Jazoon 2013 badgeIf you look at your tests, do you see a lot of repetitive patterns? Or are you looking for a way to express your intent more easily? Then, Spock might be for you. The talk “Spock: boldly go where no test has gone before” by Andres Almiray (slides on slideshare) gave a good introduction to the framework. Here is an example:

class HelloSpock extends spock.lang.Specification {
    def "length of Spock's and his friends' names"() {
        expect:
        name.size() == length

        where:
        name     | length
        "Spock"  | 5
        "Kirk"   | 4
        "Scotty" | 6
    }
}

In a nutshell, this creates three tests, running the assertion name.size() == length for each tuple of values. Here is an example how to test a stack.

But this is just one of many ways which you can use to describe tests that Spock should execute for you. The page “WhySpock” lists 10 reasons.

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – STJS: Managing JavaScript application complexity

24. October, 2013

Jazoon 2013 badgeThe talk “STJS: Managing JavaScript application complexity” by Alexandru Craciun (LinkedIn) and Nicolas Piguet (LinkedIn) focused on one of the major pains with JavaScript: It’s easy to get started, you have can quickly build a useful app which then just as rapidly turns into a maintenance nightmare (slides).

They used ST-JS as a tool to reign the dragon.

In a nutshell, ST-JS is a tool that parses Java code and converts it into JavaScript.

What ST-JS isn’t: It’s not GWT (see the FAQ). The code can be edited in your IDE, it compiles but it doesn’t run directly. The Java code is just used to allow you to write type-safe code using all the amenities of a modern Java IDE to write JavaScript. But if you want, you can implement so parts – think about sharing POJOs between your Java code and the script in the browser.

This works by writing thin wrappers (usually just a bunch of Java interfaces) to simulate the API layer of a JavaScript framework like jQuery. This code is called a bridge, here is a list of already available ones. You can then write code using code-completion, JavaDoc popups and type safety. You can apply tools like PMD, FindBugs, SonarQube (formerly Sonar), dead code analysis, …

The tool will then convert this code into JavaScript. A standard JUnit runner can now execute it by opening a browser window or simulating one using env-js and Rhino.

The output of the tool is plain JavaScript. To run it, you just need to include stjs.js which you can serve statically from your server.

As I see it, this project has the following benefits over anything else I’ve seen so far:

  • Full support from your Java IDE – Code completion, refactoring, type/JavaDoc popups, jump-to-definition, …
  • You can split the JavaScript mess easily into classes and packages
  • Not intrusive, low complexity
  • Easy to build bridges to other JavaScript frameworks
  • Allows to share POJOs between Java and JavaScript

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Test First Saves The World

24. October, 2013

Jazoon 2013 badgeThe opening keynote “Test First Saves The World” by Joe Justice introduced WIKISPEED. The project aims “to deliver a mass-production, ultra-efficient, Comfortable Commuter Car, the C3“.

You can find the current list of bugs here.

Some important points about this car: Building the first road-worthy prototype took only 3 months. A team of untrained individuals can build one of them in about one day. It runs on 2.8 l gasoline per 100 km.

In comparison: Professional car manufacturers need hundreds of people and 3 years to build something which dozens of trained teams can assemble in a few hours. And the result is either four times as expensive or pollutes the environment more.

Sounds good? They use scrum. They proved on several occasions that the method works very well for hardware, too (Forbes, CNN Money).

I agree with Joe that scrum is now entering the 3rd phase of the hype cycle: Only the most conservative companies remain cautious.

But scrum isn’t easy – if our problems were easy to solve, we wouldn’t need help, right?

While you can spend some money on training (for example, by asking scruminc to send Joe to your place), you need to remember one of the most important points of scrum: Continuous improvement.

Conclude every spring with a retrospective, identify one item that the whole team wants to have solved – more plants, better soap, an additional microwave, more light, new computers, you name it. Put that as the first item in the next spring and work on it first. Don’t forget to define acceptance criteria.

Or do you like working in a place where the general mood is that “nothing ever changes – especially not for the better”? Everyone knows that happiness and quality will make teams more productive. It’s high time to take a stand in the face of “it’s just the way it is.”

Joe’s next project? A $100 house for homeless.

What’s your’s?

Leave a Comment » | Conference | Tagged: , , , | Permalink
Posted by digulla

%d bloggers like this: