OreDev 2011 - day 3

Posted by Marcus Hammarberg on November 11, 2011
Stats
Last day was great. I didn't go to anything that was really bad and I had some real highlights with Dan North, Gojko Adzic and Mark Rendle on Zen standing out as the best.

After a short and intense Lean Coffee I'm not sitting and waiting for the keynote with Jeff Atwood, who apparently just introduced himself and then went off the stage yesterday. Let's see if he does the keynote himself today
Last day was great. I didn't go to anything that was really bad and I had some real highlights with Dan North, Gojko Adzic and Mark Rendle on Zen standing out as the best.

After a short and intense Lean Coffee I'm not sitting and waiting for the keynote with Jeff Atwood, who apparently just introduced himself and then went off the stage yesterday. Let's see if he does the keynote himself today

Jeff Atwood on StackOverflow

Jeff did the talk himself (and talked fast, fast, fast!). He talked about how programmers need rules and likes to follow (or even create) rules. Take Facebook for example - who has a "list of their friends" at home. No-one! But a geek could understand social networks by creating rules around them. A list of friend for example. 

Huh - I didn't know that Jeff Atwood did invent the game-ification part of StackOverflow by accident. By just being a geek trying to get the most out of a Q&A situation. All of it; numbers, badges etc. was just a programmer analyzing a social situation and modeling it as a game.  

Good game design forces you towards the behavior you want from your players. In Counterstrike you cannot win alone. You need to play with others and as a team. And if your anonymous or not doesn't matter.
The same on StackOverflow:
  1. You cannot win without teaching
  2. Individual skill is always inferior to communication skills
  3. Discussion is risky; sharing research and experience.
The ultimate goal is to advance knowledge in the topic for everyone. 

Discussions are not promoted because we don't learn from peoples opinions. That's why discussion type questions are downvoted. They will take up place from the questions and answers that StackOverflow wants to be the source of. 

Saying No is important to stand out and be pushed into a bland site by the community. "We're playing the StackOverflow game here. If you want to play another game (a.k.a. ask open ended questions) there are other sites". So in a way the community needs to be protected from themselves. With moderation for example. 

Tim Huckaby on HTML5 web applications for Windows 8

So I think I will try to pick up some Windows 8 information and skills during this last day of OreDev. So I'll first start with some HTML 5. Tim Huckaby is a guy is heard in a lot of podcasts. Nice to see him live.

Tim started up with stating that we WILL do HTML 5 soon. He started to give a short history of why HTML5 will be big; Apple loves it, Google loves it and Microsoft also loves it.

15 minutes left of this talk and I'm still to see code. I'm learning a lot on the history and fears of HTML5 (only 54% of the internet users today can use it, for example).  On with the code Tim!

Nope - no code in Visual Studio here. I'm a bit misled here i think. I learned something but it was more entertainment. Not bad entertainment but not very informative.

Well..... no he didn't have time. It was entertaining but I didn't learn anything of the things I hope for. Sad.

Mattias Karlsson on Java 7

I now popped into the Java track again to see a friend and colleague, Mattias Karlsson, doing a talk on the news in Java 7. I'll brace myself on asking any Java vs .NET questions in here :). Go Mattias!

Mattias is stating that the biggest news of Java 7 is that actually is out. From history we was shown that is big news since Java 6 was released in 2006. So the new release is long awaited. 

Hmmm - there's been trouble in Java-land for quite some time as I understand it from Mattias run through history. Politics and business has ruined progress for quite some time. 

Leaving that boring stuff out the news are:
  • new garbage collector called G1 - which is great news for performance tweaking.
  • Mattias showed some benchmark result for other more general performance. 40% faster than Java 6 - wow! But Mattias thought that it could be closer to 10%
  • On the concurrency side a new instruction called Fork/Join is introduced. For me it looked like a more low-level implementation of parallel LINQ. That is - PLINQ hides a lot of the things that you need to implement in Java 7. But it must be great to have it if it was missed before. Ha! Mattias recognized that the model still is very low level - I got it before him :). He hinted that a more declarative / implicit model is on its way in Java 8.
  • Also the JVM that comes with Java 7 has support for dynamic languages. With features that even Java cannot reach! We were shown a way to "invokedynamic" that is a way to via a string call a string. 
Other small changes:
  • You can switch on strings now. 
  • Improved exception - catch multiple exceptions in the same catch-clause. Nice!
  • Hehe - you can add underscores in numbers. So you can write 1000000000 as 1_000_000_000 if you like. 
  • Some better Resource management, such as external resources such as database, string or files. Nice syntax in which you can state the resources you are using in a block. Looks a bit like using in C#
  • Java 7 has improved it's generic type inference so that you have to write stuff twice
  • A new new IO - called NewIO2 :)
Mattias ended with a peek into what will come in Java8. Lamdas - yay! A first-class implementation of JavaScript running on the JVM. Cool!

Jim Benson on Healty projects

After a lunch where I had the time to talk with Andreas Öhlund about NService bus and CQRS. I learned about Amazon that actually has their read data on a CDN! Amazingly cool - distribute read data on the internet. Not even hitting your server! Cool cool cool!

OK - now on to @ourfounder Jim Benson on healthy project. He starts to say that knowledge workers works best when thy are happy. 
We got to describe the following to others in the audience:
  • What do you do at work?
  • What does your boss do?
  • What is the goal for the company you work on?
Fewer and fewer persons could answer those questions. It gets harder and harder the further away from us you get. And if you don't know the goal of levels above (or below) you you can't have a healthy project. 

We create rules to manage our organizations problem with communication between levels. The problem, however, is that those rules make us more likely to fail in following them. We "mess up" to put it short (sorry Jim, no profanity on this blog).

Jim made an argument that really stuck with me; a Kanban board is not about moving stuff fast - it's about creating quality software. I've fallen into this trap. I want tickets to move fast, but I wouldn't sacrifice quality of course. But I haven't been teaching that - I've been telling people to go fast and that's the purpose of Kanban. 

Jim tipped us on something that he called: "Subject well-being". It's simply to write a small smiley on the tickets as you finnish them. Using this technique you is less likely to smooth things over as time has passed from the time you did an awful task to the retrospective. Good tip!

Status meetings was invented by hierarchical organizations to keep them in a tight band. So if you have your status on the board - do you really need a morning meeting to communicate status? No, I say, but maybe to get a team feel and be little better each day. 

Conflict avoidance makes conflicts a lot (!) worse. And that doesn't help our project becoming healthy.

What is the definition of success in your project? Is it possible to hit that exact mark? Could it be changed? Don't over define your success criteria.

The indian company TADA hand out award for the best failure last year. The celebrate failures and act on them. 

David Evans on Time off for good behavior

David talked about how to extend the useful life of the artifacts we are creating when doing BDD (or ATDD or Specification by example...). The artifacts he talks about is the feature-files, for us Gherkin-geeks. 

David state a list of problems or syndromes:
  • A BDD specification is NOT just a test. AMEN! 
    • Script is not specifications. Very common pattern when writing based on the assumption that a feature is a test.
    • A BDD artifact is more than just as test; it's a Specification (Now), Test (Soon) and Documentation (Later) all wrapped up in one
  • Don't skimp on the descriptive parts of your artifacts
    • You should do BDD artifacts to satisfy humans, not tool.
    • Tips on User stories 
      • User stories are for Users. A system is not a stakeholder in the story
      • Don't write the solution - write why you need that
      • Put the business value first (In order to). Otherwise you risk that the last part of the story is just re-stating the first line
      • Let the "In order"-clause always talk about improvement (increase, improve). Change something on a scale. 
      • Keep the Why, What and How separated
    • Tips on Scenarios
      • Write a first simple positive scenario. Don't only have one scenarios but start with the simple, happy path.
      • Don't run away and try with every possible edge case. It's important but when we write specifications we only try to find out what we don't know yet
      • Don't write to much technical details (database-fields for example)
      • Write your Then-clause first and work your way backwards. Great tip!
      • Include a keyword from your assertion in the name of the scenario
      • Make sure that your expectations crisp and the rest will follow to be equally crisp on a as-needed-bases
      • Look out for Given that are irrelevant to the Thens
      • Keep the level of abstraction the same
      • Hour-glass shaped Scenarios; just one line on the WHEN-line!
      • Bordered edges - examples and counter-examples. 
Competing forces of a BDD document 
As the document is fulfilling different roles (Specification, Test and Documentation) we have different forces pulling in the document.
  • Scope
    • Specification: Specific
    • Test: Integrated
    • Documentation: Maintainable
  • Detail
    • Specification: Clear and terse
    • Test: Completeness
    • Documentation: Self-explanatory
BDD folks seem to be from Great Britain and use Prezi for presentation. David used Prezi to great effect. For example left a final slide that summed up the talk. Thank you, David!  

Gojko Adzic on Visualizing Quality

I had a really hard time to pick the last session. But ultimately I went with Gojko on the subject of quality. We started early but calling out examples of quality measures. Hard actually - try for yourself. How do you measure the quality to know when you're ready to ship?

Testers are in the information business! Or rather Inforvate (inform and motivate). Gojko talked about Switch by the Heath brothers. We need to inform the rider of the elephant but also motivate the elephant. 

He posed the question; What if you disabled most of your functional tests after implementation? Gojko related a story of a company that disabled their functional tests after development was done. They haven't had major bugs in production for a year. They have decided how to measure quality on business value and visualizing it.

An absence of bugs does not equal a presence of quality. We rather should measure what the people who wants the system, likes and care about. Bug count is not that important.

Try this; get your stakeholders in your room. Write down 3 things you care most about this software. You'll get more results than any developer team can deliver. Most business users don't know what they want - we need to help them.

People who ask for control really wants visibility - Elisabeth Hendrickson. Gojko related another story where they simply showed when the last content (in a content management system) was published. They just showed the waiting time. No fixing the system. The complaints - that had be plentiful - stopped.

Visualize quality

The main point is - don't measure bug counts, that is not value. That is just measuring failure. Measure whats important for the users of the system. And visualize it - you can it in a concrete and talk-about-state. 

Go and give your suggestions - visualisingquality.org

Conclusion

So with that another great stay at OreDev was over. I'm tired but happy as always after these kinds of events. Thank you everybody!


Published by Marcus Hammarberg on Last updated