Category Archives: Coding

gordon: the simple chef workflow

Coding Devops Linux Open Source

Nikolas Lahtinen, one of our top full-stack devops developers, wrote on his blog

I was working on provisioning some Docker containers with Chef.

After finding the knife commands to be verbose to a degree of extreme annoyance and knife not managing the simple task of unpacking it’s own groceries, I decided there was need for an actual Chef so I called Gordon Ramsay over!

XVnCYozNo more annoying fumbling with the knife as you try to remember whether it was cookbook site download or site download cookbook or whatever. No more combing through metadata.rb and metadata.json files for dependencies. Need to create new repository? “Where was that example repo again? I swear I had the url somehere in my emails…” Don’t worry, Gordon has got you covered!

Gordon – the apt-get of Chef

To be clear, gordon is a scaffolding app used to get you out up and running in matter of minutes. Perfect for kickstarting the provisioning files for chef-solo environments such as the virtualized kinds Docker and Vagrant provide. At the moment gordon has no abilities to communicate with Chef server other than generate static files.



Read more from:


Published by: Values

Careers Coding Company Management Strategy Work Psychology

At we have found a better way to develop sustainable software by following the core values of Agile Manifesto

Jeff Sutherland, the inventor of Scrum has elaborated the meaning of values further.

We should Individuals and interactions over processes and tools

Our core value is teamwork, which enables Collective Code Ownership and continuous learning. The sysadmins will pair with frontend developers and customers with the backend developers, trainees with senior developers. Studies have shown that when all communication obstacles have been removed, the team will perform up to 50x better than the industry average.

  • Respect for the worth of every person
  • Truth in every communication
  • Transparency of all data, actions and decisions
  • Trust that each person will support the team
  • Commitment to the team and to the team’s goals

Working software over Comprehensive documentation

By constantly refactoring the software by doing Test Driven Development, the best documentation for the software is 100% passing automated tests.

  • Define acceptance tests when defining the feature
  • Implement features serially and in priority order
  • Run acceptance tests on each feature as soon as they are implemented
  • Fix bugs that are identified as highest priority as soon as possible

Customer collaboration over contract negotiation

We have found out that the Truth doesn’t reside in our office, but we should go out of the building and find out the real customer. Since it is difficult to get the customer to come over to our office, we normally nomadically roam on-site at customer premises.

  • When the team cannot work on-site with the customer (such as consumer projects), the team must appoint a customer proxy, product owner, who is always available at the office

Responding to change over following a plan

  • It is better to adapt to change quickly rather than agree and follow a fixed contract or a plan. We have found out that even a 2 week iteration might be a too long period to fix on a certain plan, customer typically wants to change the plan even faster especially on consumer services that are in production maintaned by Devops.
  • At we unfortunately do not excel at fixed price and scope projects, but try to avoid them. Instead we provide an agile team for an hourly rate, and the customer can decide on the scope, priority and the length of the project flexibly. By prioritizing the highest value and highest risk customer stories to be implemented first and released frequently (daily or weekly), the highest business value can be delivered quickly and the total project risk diminishes quickly towards the end of the project.


The core values are

  • High Skill
  • Teamwork
  • Feedback
  • High Quality
Published by:

Rise of PHP


Ben Ramsey provides a look at the rise of PHP, the one-time ‘silly little project’ that has transformed into a Web powerhouse, thanks to flexibility, pragmatism, and a vibrant community of Web devs. “Those early days speak volumes about PHP’s impact on Web development. Back then, our options were limited when it came to server-side processing for Web apps. PHP stepped in to fill our need for a tool that would enable us to do dynamic things on the Web. That practical flexibility captured our imaginations, and PHP has since grown up with the Web. Now powering more than 80 percent of the Web, PHP has matured into a scripting language that is especially suited to solve the Web problem. Its unique pedigree tells a story of pragmatism over theory and problem solving over purity.”

Published by:

Remote teams versus On-site teams


Ville Välimäki wrote:

In the recent years the speculation weather remote teams work better than on-site teams has kept growing and growing. There are many factions with conflicting opinions about this matter and I want to share my opinion about this topic as well.

Some of my background about this before starting: I’ve had alot of experience about this subject in different companies and I’ve been involved in many of different aspects of this subject personally. I’ve worked on-site with a local team developing our own product. I’ve been developing remotely with a team for a client. I’ve also worked on-site with our own team for a client. During this time I’ve learned many of the up- and downsides of both worlds.

Read More:

Published by:

Path to the Dark Side


In coding not doing test automation leads you to the Dark Side. Yoda says the path to the Dark Side starts from Fear.

“Fear leads to anger.

Anger leads to hate.

Hate leads to suffering.”


In software development the path to the dark side starts also from fear of introducing new bugs. As a coder you start to fear that when you do a change to the system, you will break something (as often you actually do). I calculated once that for every 3 new lines of code, I introduce at least 5 new bugs. Generally speaking I’ve been observing that roughly 20% of all work is related to rework (in accounting, marketing, system administration, also software development) for a “professional team” that is experienced and knows their trade well has not done any special efforts to improve quality, such as Six Sigma or Zero Quality Control. I observed the defect-work ratio of my own work in Nokia, and for my surprise I was unable to introduce any improvement for over 2 years (when not doing any special effort to improve, other than just measuring).

The management fears that their new system does not work, or the customers won’t buy it once introduced, and thus postpones the launch dates to fix a few more “major” bugs and to introduce a few more “critical” new features. This management fear slows down the the go-to-market times, creates waste of excess non-released inventory of unfinished work, and slows down the big wheel of adapting the company and products to always changing market demands, which can be fatal especially for start-ups.


In agile projects, Fear prevents you from doing Refactoring causing ever increasing Technical Debt, which will cause project failure typically within 18 months (according to my experience). You start to feel angry about the huge piles of the spaghetti, bad coding practices and architecture, and also the exponentially increasing number of bugs and time to fix the quality problems. Management feels angry about the steeply increasing operational costs, bad feedback from the customers and lack of progress in new “business critical” functionality.

You notice this when somebody starts to talk about the so called Version 2.0 (i.e. complete rewriting of the application, because reasons x,y and z). Throwing away your previous work effort is a large scale waste.


If you are angry enough about your bad quality code, you will start to Hate it enough that you start to consider restarting from a clean slate as a better alternative. However, unless you fix the original reason for Fear, you will just repeat the same cycle within the next 18 months. You start to hate your work, hate your management, hate your co-workers.


In the end you suffer and feel miserable about your life, but this is how the software development has been always done before. You are trapped into the chaos of Dark Side without way to escape the corruption and cycle of project failure.


At we fight the Dark Side of coding by embracing Behaviour and Test Driven Development (TDD, BDD) and test automation. Having a high test coverage and 100% passing unit tests, run constantly by the Continuous Integration server helps you to release from the fear of doing change. Actually you can start to Embrace the Change to achieve happiness both personally and professionally, and also create Sustainable Software with longer than a few months life-cycle (we target projects that stay maintainable for decades).

Published by:

Editor Fascism to promote Pair Programming

Coding Software Engineering

At we have been recently listing our software engineering practices to find out a better overview how we should improve our Extreme Programming process adoption. In 2008 we managed to reach a near perfect XP process by having 28.5/29 practices in use, evaluated by a bi-weekly self-assessment. On this week I added yet six more practices to the list, which were previously not listed or regarded as a practice, but were actively used.

Editor Fascism to promote Pair Programming

This is our latest addition to our process description, but it was actually taken in to use already in 2005. The idea of Editor Fascism is to force all developers to use the same development environment and especially text editor. When we started to use XP in 2004, the main obstacle for adopting pair programming was that each and every developer used his own text editor of choice. For example we had coders who preferred vim, others who were emacs -fanatics, I like pico/nano and Textpad (it’s the only editor that can open 1GB file in a second and not to crash that I know). Today we have people using Aptana studio, Netbeans etc. Anyway, the picture is clear: it is difficult to pass the keyboard to your pair if he doesn’t know vim commands, or if the vim -coder doesn’t know Netbeans shortcuts. While it would nice to learn how to use all editors, I thought that we receive a better ROI by investing in standardization of the routine tasks so that we can focus our learning energy to more complicated and value adding activities (such as test automation).

Our Editor Fascism currently means that all office development machines that are used for Pair Programming should have Eclipse installed and properly configured with all required plugins. We should have debugger working, a common configuration loaded with coding convention settings and auto-format, templates, common keyboard shortcuts etc. All programming must be done by using Eclipse, there are no alternatives. Period.

If you want to use another editor, you can not. That’s it. If you don’t like that it’s the reason why we call the practice Editor Fascism :)

In 2005 we quickly learned that this was a very quick way to promote pair programming, at least it abolished most of the technical and practical obstacles. Secondly I have noticed as a manager that the productivity of the team has simultaneously increased since everybody are using an advanced IDE instead of a basic text editor. Recently I have been also thinking about Zero Quality Control and Eclipse is a very good to provide the quickest possible Feedback cycle to prevent defects by providing immediate in-line syntax error warnings. By using a text editor it takes a minute or two to get the same feedback from the compiler, the browser or the server, which grinds down the development productivity on the small scale.

Published by:

Usage of Private and Final in Java discouraged


Recently I got stuck on an old consideration of mine related to usage of private and final in Java. The Private -visibility declaration limits the methods’ or properties’ visibility to the class itself only, and declaring something as final prohibits declaration of any further sub-classes. Final might also allow some minor performance optimizations on some Java JDKs.

While this is not a programming language specific problem, I have learned since that declaring everything to final is almost considered as a best practice in Java (see ). Eclipse often auto-suggests declaring variables as final, so it might seem like a good thing to do (but is not).

Personally I have thought about the usage of private and final in Java and Object Oriented programming, and found little use for them. Declaring methods or classes final makes code-reuse by inheritance difficult. Similarly the default usage of private makes code-reuse to require always a change to the super class (you need to re-declare it as protected). If you are using a framework or a library (such as Apache Wicket) with final classes or methods, or the java.lang.String, you might be out of luck unless you fork and recompile the whole dependency tree and related libraries. Thus, I personally strongly favor declaring everything as non-final and protected instead, by default. This leaves the future extensions and code re-use possibilities open, and doesn’t artificially undermine the core promises of Object Oriented programming (of code re-use and encapsulation).

The second downside of overly usage of privates and finals is making the unexpected future usages of your code much harder. Recently I got excited about LambdaJ and the possibility to use functional programming style in Java to make the iteration over Java Collections to look nicer and shorter. The rise of functional programming was probably not something that Java core architects or Apache Wicket’s developer had seen in advance when they initiated their projects. However, a major hindrance of the otherwise excellent LambdaJ library came from the Java practice of declaring everything as private and final in Java. For example you cannot use LambdaJs basic select() -operation to String, because it is declared as final. See my other article on LambdaJ. I hope that Java 8 brings some relief to this problem, but it is also a matter of coding convention.

Do not declare anything as final or private, unless there is a REALLY good reason for it. Use non-final methods and protected visibility instead.

Published by: