NDC Oslo 2013, day #1

This time it's going to be a report from day #1 on Norwegian Development Conference.

 

Key note

Done by Joel Spolsky. It was interesting talk about the community he created around his stackoveflow.com site and all related sub sites. The main goal of any website/community and the reason the site is so popular is that:

know, focus and clearly define your business area (community) you want to focus on, make a business from

 

 

Accelerating Agile: hyper-performing teams without the hype

Performed by Dan North. The guy I met in our office already. 

He shared his experience working in a trading/risk SW development team.

How to organize the team, the work, etc. to get high-performing team:

• new people on-boarding matters
  • make sure the team is prepared for new member, all dev "toys" are prepared
  • avoid giving newcomer long documentation, etc. - just remembered my start in the previous company
• each day the team has 2 standups - morning stand-up and before end-of-day the demo to product owner so that all are on the track, the work is demo-ed
  • approach we use often, just coupling it together with morning stand-up meeting
• plan the work but for short time, 1 week is the most appropriate, 2 weeks are acceptable
  • as usual, planning is essential, plans are useless
• working in the distributed system 
  • tooling support for agile team doesnt matter, keep it simple, use board, sticky-notes, make a screenshot and publish it on the board (results in presenting them on the retrospective meeting, in form of chaining screenshots)
• learning morning or lunches, no powerpoint presentations, pure coding, no excuses if somebody is missing
• share the love within the team 
  • pairprogramming (results in the best code), 
  • do code review -> less shocking, more learning, ask new members to do codereview - more learning about the code, startup
• DO learn new languages, programming styles (CSP, actors, fork-join), SCALA, Go, Closure
  • the main goal is to learn from others, to get other ideas which could be useful in your daily work
• Functions, objects ~ namespace vs. classes/prototypes in dynamic languages
• Prioritise risky over valuable. You don't want: value, value, value, showstopper, sorry, we have to throw that away
  • implement first with risky stuff then values

 

All in all, great talk, worth watching online when the video will be available.

 

 

The Abstractions of AngularJS

Done by Scott Allen. 

 

• it's used for one-page applications, which is very similar to WWA applications
• simple usage for simple problems
• based on MVC pattern
• having dependency injections (DI) in Javascript solved:
  • translate function code into string, take first line of the method containing the signature, parse it and use internal DI service
• data binding, DOM manipulation, animations, UI extensions etc. is done on developing so called "directives" which are used as the attributes on the DOM elements
• defines very clean separation of concerns (MVC), constraints the developer from misusing MVC pattern
• Knockout vs AngularJS - more religious decision but Angular keeps the patterns strictly followed but could have performance issue

Comparing to WinJS for WWA apps, I'm more than happy to stay with WinJS, just missing more business application support from WinJS: dependency injection/resolution support.

 

 

Do it right, then do the right thing

Main message:

• keep short iterations, development and deployment cycles 
• develop a feature together with feedback gathering logic (i.e. usage statistic), make customers to give you the response, release the feauture, inspect/analyze data and adapt change and again. All in short iterations.

 

 

Patterns of Effective Teams

Again, Dan North, again great talk!

The talk was going around the following map:

 

Patterns

Dreyfus Squared

• Different levels of people, do the pairing!, share the love and knowledge within the team

Shallow Silos

• Rotate team/pairs

Seize of Day

• Energize standups, discuss the status, not just report!, we don't care about the brief status: I did XYZ, I will do ABC, I have no issues. Do the real scrum as it was inspired from american footbal to decide what the team will do now, today and how it's going to solve the current problems.

Near and far

• Cross-funcational teams vs. single specialized teams
  • solution in the middle, keep having very specialized teams but ask them to teach cross-functional teams

Warm welcome

• already covered in his previous talk

Code Critique aka code reviews

• Learning from others
• Socializing

 

Team Hack Days

• "TODO" days
• "SMELLS" days - fix the smells in the code, I know, you don't have smell in the code, just in case ;)
• "RESEARCH" days
• go and play with non-project tasks
• => getting people together, great ideas can evolve

 

Walk a mile:

• What's the benefit of person (dev, manager)
  • Walk in his/her shoes
  • Take him off and let's see

TDD

• Can slow down in case I don’t know where you are heading to, i.e. prototyping, proposing different solutions, 
• Find a balance where it's needed, some simple code could be verified by explanatory tester and it's wasting of dev time

 

 

You are not (only) a software developer! - Simplicity in practice

Done by Russ Miller.

Very common problem is over-producting. SW devs tend to write the SW to have fun during the coding, creating over-complex code instead of solving business value in the most simple way. 

The main goal how to solve the business issues:

• create impact map, use 5 why method, root cause analyzes
• explore the problem before writing the SW 
• move from delivering valuable SW to delivering the valuable change and SW is just one of the options

 

 

Faking Homoiconicity with graphs

Done by Mark Seeman.

Some languages (most notably LISPs) exhibit a characteristic called Homoiconicity, which means that code is data and data is code. This makes a language very powerful because a program can inspect and manipulate itself.

• Complex business logic with many if/else statements is very hard to test. Solution is to transfer business logic/code into data + behavior, example mortgage contract rendering processor
• Inspect the code and extract the common interface, i.e.
  interface IRendering {
  IEnumerable<IRenderingNode> Render()
  }
• Apply composition
  class Renderer {
  IEnumerable<IRenderingNode> Render() {
  for(var renderer in this.Renderers) {
  yield return renderer;
  }
  }
  } 
• The result:
  • Write test for general compositor to prove the code works
  • Write small tests for each different render
  • Total amount of the tests is smaller, the business logic is covered by tests, design is clean, SOLID principal applied => ALL good.

 

• Could apply testing by example
  • setup compositor (i.e. renderer with rendering nodes) 
  • serialize it into data! - JSON, XML, 
  • transform it to business readable form (i.e. HTML) and 
  • communicate with the business, 
  • make them verify it => specification/definition by example

Summary

I missed many other sessions but all videos will be published out on the internet in a week or two.

That's all for now.