Our company sales reaches 1.11M EUR in 2015. Good work!
See a nice video on Pair Programming and Rule of Two. Pair work is not only a programming practice, but is a standard military practice ( https://en.wikipedia.org/wiki/Wingman and https://fi.wikipedia.org/wiki/Taistelijapari ) can be applied to any knowledge work such as sales and accounting, too.
Pair Programming is a agile practice with 2 people in front of 1 computer and keyboard. There are 2 roles: the Navigator one tells what to do, the Driver holds the keyboard and writes (“one police man can read, the other can write”). You switch the roles frequently. Seniors should be paired with Juniors, Customers with Coders and Sysadmins with Frontend Developers.
Pair Programming is a controversial practice where doing pair programming wrong is worse than not doing it at all. There is a vast amounts of scientific findings related to pair programming:
Programmers working in pairs usually produce shorter programs, with better designs and fewer bugs, than programmers working alone. See http://en.wikipedia.org/wiki/Pair_programming
- Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs; they also catch design defects early.
- Pairs usually complete work faster than one programmer assigned to the same task (but it takes 2x the effort, but this is better than well compensated by the improved productivity)
- Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email
- Additional benefits reported include increased morale of the team.
While Pair Programming works for the Sith, it is known to be kryptonite for
- incompetent introverts
- control freaks
- super hero programmers
- cowboy coders
More pair programming information is available from
Today we were fixing some old unit tests for our large marketplace software, when I stumbled upon a peculiar test case. The test, written in 2005 assumed that a suitable date far in the Future would be 2015-01-01, and was now failing.
Anyway, the morale of the story is that at least at PHZ.fi, where we endeavor to build Sustainable Software, let’s expect that our software will be used for more than 10 years, before somebody rewrites it! In our case we are still using more than 10 year old software, but since we have unit tests (that now pass 100% again), it can still produce (a lot) business value. For a developer building sustainable software over building low quality, throw-away software, makes a big difference on the impact you contribute to the world.
I’ll give you a rant about PHP 5.3’s “latest” addition of namespaces. I think this is a harmful concept in PHP, a “new” feature that needs to be understood correctly before using. My short advice for all PHP developers is: DO NOT USE NAMESPACES. I’ve seen many PHP developers in our own company and customer projects, who have started to use namespaces just fort the sake that they are new, and not knowing what they are really doing. With my background as a Java developer I can give a better perspective.
In Java there is an actual use for namespaces. Java features package visibility, which I nowadays favor over public or protected (and protected over private) because package visibility (and namespaces) can be used to create nice unit tests by putting the tested class and unit test in the same namespace. In PHP there is no package visibility, so there is no need for namespaces.
In Java, the namespaces (packages) are a very rigid system that cannot be configured in any way. However, the greatness of PHP is that there is a very dynamic and powerful mechanism called autoloader, which can be used to configure your “namespaces” as you wish. A typical legacy way to build PHP package-like -structures was for example in ZendFramework a convention to put conceptual modules in separate directories, and have an autoloader to load the classes from the corresponding directory.
However, now when an actual namespace is implemented in PHP core, many developers like to give it a try and start to use it everywhere. The outcome is that all good parts of PHP start to fade away. The classes start to get polluted with useless boilerplate just for the sake of having namespaces. Useless, hard-to-read and difficult to write use-statements have appeared to PHP classes from C and Java (and other legacy 3rd generation low-productivity languages). This is clearly bad at least from project management and productivity perspective.
When you are using PHP namespaces, all changes to everything become difficult. You are also lacking IDE tools from Java that would auto-generate your “use” statements. Since there is no real benefit in using namespaces, you will just shoot yourself in your own leg by using namespaces in PHP.
The only legitimate use of namespaces that comes in my mind is when you develop some open source, abstract, non-concrete (see http://stackoverflow.com/questions/1031135/what-is-abstractness-vs-instability-graph ) library software that would be included to your composer.json by thousands of other projects. However, if you are developing your own, concrete, non-library software for your customer or own use, all classes that you define should be in your “root namespace” and adding any other namespaces will just make you hurt. You are not probably going to offer your software publicly available to the Internet, in which case there is no need to publish a public namespace to the world, and slow your development work by adding all the boilerplate required to do so. In 99% of the cases you are doing the first, and you don’t need any namespaces for you own software.
So, DO NOT USE NAMESPACES IN PHP, unless you know what you are doing.
PHZ.fi sales for 2015 has exceeded 1 million euros by 11/2015. Since there is still one month more to the year, our estimate is to reach 1.1M EUR in sales for fiscal year 2015. PHZ.fi has 17 employees.
Suomen Asiakastieto nosti PHZ.fi luottoluokituksen parhaaseen AAA-luokkaan 14.11.2015.
We found out a problem with Nokia Lumia 820 and Windows Phone Outlook 2010 not syncing emails but giving error 800C0000. After some debugging we found the following solution that is now added on on our email usage instructions page:
Problem: Nokia Lumia 820 Windows Phone Outlook 2010 says error code 800C0000 while synchronizing emails.
Solution: This problem is a bug in Windows Phone Outlook 2010 client caused by bad email content such as special characters. Other email clients can handle this situation, but Windows Phone unfortunately not. Typical problematic characters in emails might include for example:
The issue can be resolved by moving the offending email to some other sub-folder. Log in to webmail: https://mail.phz.fi then search for special characters not displaying properly. Select the message by clicking the check-box on the right. Use “Move” button to move the message to some other folder (such as Drafts).
We found out that we don’t yet know a good way to write down our Personas and their Goals in a coherent way. There is also a problem in teaching the ways of Goal Oriented User Interface Design (GUIDe) to new interaction designers.
On the Internet other people than myself have also been considering the process how GUIDe can be
which are very similar to my thoughts about integrating GUIDe and Extreme Programming: http://pharazon.org/publications/GO-XP.pdf
However, the Extremeplanner’s article didn’t mention any way how to describe the Personas and Goals. I think we should create a Domain Specific Language (DSL) to make it easier to write realistic goals that leave the design (workflow) open for designer to re-invent.
The power of Goal Driven UI Design comes from freedom to redesign the technical solution within the limits of current technological possibilities – the designer should be as open minded as possible to find out the what possibilities there are to use “teleportation”, “magic” or “zen” in creating a design that employs 0 steps to achieve the Goal.
Jeff Sutherland explains how Scrum was originated.
Key to the success: Make work visible
Every morning, there’s a bullet coming at you with your project’s name on it. If you follow the plan, you will be taken down. Most of the project managers don’t get out of the way. 84% of IT projects are failures.
In the daily meeting we need to debate what is the next item in the sprint backlog that we would implement that touch which component that would cause the biggest impact in the system that would emerge a new capability. The minimal change to push the capability forward.
The whole team needs to know the architecture of the system and they all needs to argue about where they touch the system to systematically produce the feature in the shortest time possible.
Conway’s Law: the culture of the organization reflects in the system architecture – you need to create an object oriented organization
“Pienet ja keskisuuret yritykset ovat viime vuosina yhdistäneet voimansa julkisissa kilpailutuksissa. 75:stä it-alan yrityksestä koostuva Atrain pärjäsi keväällä ratkenneessa Valtion hankintayksikkö Hanselin kilpailutuksessa.
Atraimen edustajat pitävät omaa toimintamalliaan ylivoimaisena. Kyseessä on verkosto, joka on syntynyt julkisia kilpailutuksia silmällä pitäen.”
PHZ.fi on osana Atrain-ryhmittymää. Lue koko artikkeli: