And I mean full, I don’t have any hard data to support my statement but my one month experience here and comparison with my home city (Poznan) that is same size as Oslo. And even if % of people who are typing lines of code here is not really higher at least they are way more active and passionate of what they do.

.NET Users, Windows Phone Developer Community, The Oslo Lean Meetup, Extreme Programming Group, Java Developers, heck! - there is even a Delphi users group. No to mention that local software houses, consulting firms, etc. are really interested in growth of their employees and they actively invite speakers outside of Norway.

I have visited Test-Driven Development with JavaScript and node.js organized in an office of one of Norway’s software houses (60 people attended, and right after there was an XP meeting with more then 100 registered – quite impressive). First speaker was Norwegian, but fortunately after a short survey whether there are or not non Norwegian people at the public they decided to have this talk in English (it turned out that only for me – thank you :-)!). BTW Norway is truly amazing country where everyone, and I mean everyone can speak English (yes, even 80 years old people and drug addicts). I met some really nice people there, very passionate about what they do.

This week however I experienced something completely new. I attended a meeting that was a form of Coding Dojo. According to Coding Dojo website it is:

.. a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills.

Host of this meeting was Jon Jagger, a truly passionate guy who created http://www.cyber-dojo.com/. As he states on this webiste:

I built CyberDojo so you can practice and learn about:

• coding and test driven development
• team dynamics and collaboration

Now please try to imagine, around 8 notebooks, pair programming, 5 minutes of time between group change, C#, C, Java, Python, Ruby and one Roman Numbers problem :-) It might seem like a chaos at the beginning, and yes, it was hard to get to the working solution, but for me lesson of importance of red, green development, leaving your code in a state that work can be continued right after you left, getting closer to the solution in a small steps was really valuable.

If you can ever have chance to experience such a thing, I do strongly encourage you to do this, you are going to learn a lot about your team working skills.

While thinking about Toyota Way it is hard not realize that many of principles that driven this company success are not really something new. They were “alive” for many centuries - since mankind ever tried to conduct any bigger project. One of them is simplicity – in Toyota there is no place for bureaucratic, overblown mindset.

Recently I stumbled upon Occam’s Razor law, also known as Latin expression Lex parsimoniae. It is one of those rules of thumbs that driven many outstanding minds of few last centuries (including Albert Einstein, Leonhard Euler, Isaac Newton).

The Principle of Plurality - Plurality should not be posited without necessity
The Principle of Parsimony - It is pointless to do with more what is done with less

Although they seem obvious, The Principle of Parsimony is something that can be really taken into hearts of many software developers. Creating overblown solutions just to shoot “the fly” is a common problem – and if you have a problem first step is to admit it ;-)

First sin is to create architecture way to complex for current project. Do we really need DDD in simple web app ? Maybe Unit Of Work pattern with conjunction of Linq To Sql is enough ?

Another problem is adding features that seem “necessary”, but in the end our client is never going to use them because from his perspective they are useless. This subject is mostly covered with Agile movement, but still it is a quite common behavior among software developers.

I truly believe that this law is really accurate in almost every aspect of developer’s life – e.g. documentation should be concise, and should cover generalities without getting lost in details.