Loppuviikosta PHZ Full Stack Devops -tiimi pääsi välillä ulkohommiin kentälle. Pakkanen häiritsi hieman AWS deployment:ia ja lisäämme sormikkaat Devops-varustepakkiin (ja kunnon etähallinnan IoT -laitteisiin).
The latest (disclosed) PHZ customer project working on-site at customer premises hit on the last week the record of fastest Extreme Programming (XP)-process adoption seen this far. The previous scores have been:
- 31.5 practices in 5 years at CMAX.gg
- 30 practices in 2 years at Oikotie Real Estate -portal
- 28 practices in 3 months at Apprien and Responsive Image Cache
The latest record is to adopt 30 and a half practices in just 6 weeks! Our current Extreme Programming list of practices include for example Pair Programming, Test Driven Development, 100% Code Coverage and Continous Integration (to test and production environments). There are currently total of 37 practices, with the Lean 5S being the latest addition.
The benefit of having such a high XP -process maturity is that roughly after 25/37 practices the software engineering team starts to break even for the customer, i.e. they cost the same as they produce. At 30 practices the team typically produces more than they cost, and near 37 practices the team hits so called super-productivity enabling the delivery of world-class products at very high efficiency. This is the way how we claim our main sales proposition of delivering Sustainable IT Services where the life-time of the systems we deliver can reach decades compared to the few years or months when using more traditional practices.
Benchmark:asimme hiljattain suurimpien toimittamiemme projektien tuottamia lopputuloksia, ja löysimme kestävän kehityksen ja korkean laadun ideologiamme tuottaneen asiakkaillemme rahassamitattavia ja huomattavia konkreettisia säästöjä.
Eräässä projektissa edellinen toimittajan tekemistä tehtävistä jopa 44% oli bugikorjauksia. Kyseisessä projektissa jossa PHZ Devops-tiimi vastaa kokonaistoimituksesta hyödyntäen testiautomaatiota ja jatkuvaa toiminnan parantamista, virheiden määrää on saatu tiputettua 5.7% tasolle eli lähes 8 kertaa aikaisempaa pienemmäksi. Laskiessa huonon laadun kustannuksia projektin kokonaiselinkaaren mitassa, uusi PHZ Full Stack Devops -toimintamalli on jo tähän mennessä tuottanut huomattavia säästöjä ja on nähtävissä että säästöt tulevat kumuloitumaan miljooniin euroihin. Samalla tuoteomistajat ovat voineet saada käyttöön jopa 8 kertaa aikaisempaa enemmän uusia ominaisuuksia, mikä on lisännyt myös palvelun käyttäjämäärää jopa 20%.
Ota yhteyttä sales (at) phz.fi tai myyntijohtaja Anne Lamberg 045 662 4501, jos haluat kuulla tarkemmin kuinka voisimme parantaa myös teidän yrityksenne ohjelmistokehitysprosessin tuottavuutta.
There is a heated up debate going on among software development professionals about what is the difference between Agile and Lean software development? Are they rooted in the same principle or is there something fundamentally different between the two methods?
James O. Coplien explains the difference:
At PHZ.fi we are embracing both the methodologies, in particular Extreme Programming by the book, and eliminating the waste by reflecting on Kanban, Total Quality Management, Six Sigma and Shigeo Shingo’s Zero Quality Control.
Time after time I explain to the other coders that private visibility is harmful, 95% of coders tend to try rock hard claim otherwise. Unfortunately private is a harmful visibility level to use.
Personally I haven’t yet found any legitimate use case for private -visibility, but the opposite. Quote from the documentation of a unit testing framework:
Limitation: final, private, and static methods
Please note that final, private and static methods cannot be stubbed or mocked.
Using protected visibility instead of private by default has the advantage of leaving the opportunity for the future developers open to reuse and extend your code. Using private denies this opportunity and forces rewrite of your code. For test classes using protected is however clumsy, since you need to create a subclass to be able to mock or stub the methods or properties you want. Using dependency injection would be a better idea.
PHZ.fi has been conducting a range of code reviews for half a dozen large softwares with 150-600k lines of code. My surprising observation has been that in all the cases the code has been consisting 80% of public methods. The real life outcome thus seems to be that coders don’t really use encapsulation so often and limiting the visibility on class level is less common than using hidden interfaces (e.g. private). Of course a function is also an interface for encapsulation, and thus the one can also deduct that the coders are mostly hiding the implementation details inside one or only a few public methods rather than using large number of private methods.
In Java my best practice is to define all non-public properties and methods on package -visibility, meaning that there is no public, protected or private. If you place your test class in the same package, you can easily access also the non-public the methods or properties and for most of the time you don’t even need DI configurations.
Our Aalto University open source student project RIC developing a Responsive Image Cache system by using the Go language has released a couple of very cool features.
The project idea is to offer the ultimate solution for web responsiveness for the increasing variety of mobile devices. Instead of offering for example just 3 break points with a few different image sizes, or preconfigured image sizes, RIC automatically detects exactly the right view port size for each image and device, thus offering precisely the best possible image for each user.
For example, if you request the image asset id 123456, RIC automatically detects whether your browser supports .webp format. If not it will try the next best .png, and fallbacks to .jpg and .bmp images. See for example this image where, you don’t need to specify the format, RIC picks the best option for you:
The latest two new features includes liquid rescale by adding ?mode=liquid to the img src url.
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.