Author Archives: Hätinen Antti

About Hätinen Antti

Managing Director for Pharazon AB

PHZ.fi ja OP sopivat 500 000 EUR rahoitusratkaisusta

Careers Company

PHZ.fi ja Osuuspankki sopivat joulukuussa uuden rahoitusratkaisun, joka lisäsi yrityksen rahoitusta jopa 500 000 EUR:a. Uusi rahoitus mahdollistaa vahvan menestystarinan ja kasvuvauhdin kiihdyttämisen aiemmasta keskimääräisestä 80% per vuosi -kasvusta kuluvan vuoden aikana.

Yhtiön palveluksessa oli vuoden lopussa 39 työntekijää, mutta toimitusjohtajan mukaan uusia kehittäjiä tarvitaan heti kaikkiin teknologia-alustoihin niin Java, Node.js, bigdata, frontend (React, Angular), Ruby, .Net, pelikehitys (Unity) kuin Devops-puolelle. Tämän lisäksi yhtiö hakee myös monitaitoisia graafikoita uudelle projektit -liiketoimintaosastolle.

Published by:

PHZ.fi myynti nousi +90% 2.1 miljoonaan euroon

Company Start-up

Alustavan laskelman mukaan PHZ.fi myynti nousi edellisvuodesta +90% saavuttaen 2.1 miljoonaa euroa vuonna 2016. Tämä jatkaa neljättä vuotta putkeen keskimäärin 80% vuosikasvua. Yhtiön palkkalistalla oli vuoden lopussa 39 henkeä.

Kiitokset kaikille työntekijöillemme, asiakkaille ja yhteistyökumppaneille erinomaisesta vuodesta! Vuonna 2017 menestystarinamme on tarkoitus jatkua samanlaisena tai jopa kiihtyä.

Published by:

New Extreme Programming Adoption Record – 30.5 practices in just 6 weeks!

Careers Coding Company Software Engineering

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:

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.

Published by:

PHZ Full Stack pienensi bugien määrää -780%

Coding Devops

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.

Published by:

Etsitään Full Stack Web -Tuottajaa

Careers

PHZ Full Stack Oy hakee palvelukseensa kokenutta ketterää Web-tuottajaa asiakasprojekteihimme. Tule mukaan huippuosaajatiimiimme!

PHZ.fi on IT-projektiliiketoimintaan keskittynyt ketterä ohjelmistoyritys, joka myy Web ohjelmistokehityskonsultointia digi- ja mainostoimistoille, media-alalle sekä muille yrityksille, toteuttaa asiakkaille IT-projektien kokonaistoimituksia sekä kehittää omia tuotteita. Toimialoina vahvimmat ovat asuminen ja majoitus, maksuliikenne ja eCommerce-järjestelmät. Panostamme vahvasti Lean- ja Agile-prosessimalleihin (Extreme Programming) ja olemme toimineet TDD-periaatteiden mukaisesti jo vuodesta 2004 alkaen. Haluamme palvelukseemme vain ohjelmistoalan parhaat tekijät, jotka palkitsemme hyvillä henkilöstöeduilla ja keskimääräistä paremmalla palkkatasolla.

Web-tuottaja hoitaa kommunikoinnin asiakkaidemme kanssa järjestelmän vaatimuksista sekä koordinoi käyttäen ketteriä ohjelmistotuotantomenetelmiä UX-suunnittelijoita, graafikoita, frontend- ja backend-kehittäjiä järjestelmän toteuttamisessa aikataulussa ja budjetissa. Mikäli Full Stack Web-tuottaja ei löydä reusrsseja jollekin osa-alueelle, hän pystyy tarvittaessa toteuttamaan koko projektin itsekin.

Minimiosaamiset

Projektipäällikkö web-sivuprojekteille
Asiakassuuntautuneisuus ja kommunikointitaidot
Joko ohjelmointi (esim. PHP) tai graafinen osaaminen (Photoshop).
Tiimityötaidot, pariohjelmointi/-työ
Web-analytiikan perusteet
CMS -käyttökokemus esim. WordPress, Drupal tms.

Työtehtävät ovat pääosin asiakkaiden tiloissa eri puolilla pääkaupunkiseutua. Teknisen osaamisen lisäksi edellytämme hyviä tiimityö ja kommunikointitaitoja asiakkaan kanssa toimiessa.

Lähetä CV:si osoitteeseen: rekrytointi@phz.fi

Lisätietoja

Toimitusjohtaja
Antti Hätinen
+358505688732
antti.hatinen@phz.fi
PHZ Full Stack Oy

https://www.phz.fi

Published by:

Join the Light Side of the Force

Careers

yoda-922520PHZ.fi is a Helsinki based Full Stack IT company focusing in Sustainable Life Cycle IT Development by using Test Automation and Devops -practices. We believe strongly in Lean & Agile (Extreme Programming) principles such as Pair Programming, Continuous Delivery and Test Driven Development.

Our total revenue in 2016 is 2M EUR and we are growing at an annual 81% growth rate.

Avoid the anger and hatred caused by spaghetti code, and join us to build A Better Tomorrow!

Send your CV to recruit (at ) phz.fi

 

Published by:

Lean vs. Agile

Coding Software Engineering

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:
http://www.slideshare.net/jcoplien/20090513resund-agile

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.

Published by:

private considered harmful

Coding

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.

Published by: