Ibuildings blog

In de softwareontwikkeling kunnen we veel leren van productiebedrijven. Vooral om softwareontwikkeling beter en efficiënter te maken en om het meer doelgericht te benutten voor het succes van organisaties. Het per stuk productiemodel biedt daarbij uitkomst, ook voor software. Dit zou de (nieuwe) ambitie moeten zijn voor iedere organisatie die te maken heeft met softwareontwikkeling.

De nieuwe werken bij Ibuildings website is live en daar zijn we uiteraard erg trots op! Met de nieuwe website willen we laten zien hoe leuk en uitdagend het is om bij Ibuildings te werken. We laten zien hoe het achter de schermen is en willen hiermee de sfeer bij Ibuildings laten proeven. Zo hopen we jou enthousiast te maken om bij Ibuildings te komen werken. Lees meer over onze kernwaarden, hoe wij werken en aan wat voor projecten wij werken.

Door de digitale transformatie die organisaties maken, ontsluiten zij vaak informatie via fraai vormgegeven websites en applicaties. Wie verder kijkt en denkt, zet soms ook al de volgende stap: de ontsluiting via een API (Application Programming Interface). Dat biedt veel kansen, maar organisaties zien het vaak ook als een moeilijke stap. Maar wie zijn software infrastructuur aanpast, zou ik zeker adviseren de stap te overwegen. Zeker als je bedrijf (steeds meer) meerwaarde biedt met data of informatie.

Ibuildings organiseert elk jaar een internationale conferentie rond PHP technologie: de Dutch PHP Conference (DPC). Afgelopen week was alweer de 11^e editie van onze succesvolle conferentie waar zo’n 630 developers, software architecten en community leden in de Amsterdamse RAI bij elkaar komen.

Als maatwerk bedrijfssoftware veroudert, wordt bij veel organisaties haast automatisch gekozen om volledig nieuwe software te laten bouwen. Aan renoveren wordt vaak niet gedacht. Terwijl dat in 70 procent van de gevallen succesvoller is en goedkoper. Het is een interessante optie, die ik in ieder geval altijd zou overwegen. Want in die oude applicatie zitten vaak grote schatten verstopt. 

Om te focussen op kernactiviteiten weten organisaties vaak heel goed welke taken zij zelf moeten doen of kunnen uitbesteden. Maar zodra het gaat over de software die dezelfde corebusiness ondersteunt, wordt daar opvallend genoeg minder rechtlijnig over gedacht. Mijn advies? Sta voor die kernfunctionaliteit eens goed stil bij het houderschap en eigenaarschap en behoud zelf de regie over je bedrijfskritische software.

Nu organisaties steeds vaker bewust de omslag maken van ‘business’ naar ‘online business’ worden webapplicaties en ander software steeds meer bepalend voor hun succes. Bij de keuze tussen ‘maatwerk- of  standaardsoftware’ wordt een mixvorm steeds interessanter, maar hoe vind je de perfecte balans? Focus daarvoor op je kernfunctionaliteit.

For many years Ibuildings has had a formalized way of reviewing people's skill sets. This system enables tracking of skills and relative changes in those skills over the years, across the organization. This has been used as a means for estimating a person's salary and appropriate changes to it, as well as opportunities for personal development. In early 2016 we recognized that the technical part of this system needed an update. So I started working on a new list of technical skills.

A summary and review of the talks I attended at the third day of BuildStuff Lithuania, 2016: "The Biggest Trick Consultants Ever Pulled was Convincing the World Continuous Delivery was Easy" (Paul Stack), "Javaslang - Functional Java Done Right" (Grzegorz Piwowarek), "Edge-free Programming" (Michael Feathers) and "Functional C++" (Kevlin Henney).

A summary and review of the talks I attended at the second day of BuildStuff Lithuania, 2016: "Teaching your Team CQRS/ES 2.0" (Chris Condron) and "Functional Architecture: The Pits of Success" (Mark Seemann).

A summary and review of the talks I attended at the first day of BuildStuff Lithuania, 2016: "The Long Sad History of Microservices (TM)" (Greg Young), "Metrics Driven Development" (Sam Elamin), "Around Learning" (Alberto Brandolini) and "Decisions, Decisions" (Dan North).

Last Friday I attended the DomCode conference in Utrecht. This is a very friendly, inclusive, welcoming conference. Organisers Aisha Sie, Lucas van Lierop, Ross Tuck and their extensive team of volunteers did a wonderful job at fixing all the big - and small - stuff. They succeeded in attracting ~275 people to come to the capital of our province, Utrecht, where coincidentally one of the Ibuildings offices is located too. In fact, Lucas van Lierop is one our employees, and Ross Tuck has been one in the past. So it only made sense for me and several others of the Utrecht team to attend the conference, and even help out during the day.

Bamboo and BitBucket are both Atlassian products. They work together nicely and you don't have a lot of configuration to do, so they’re perfect for a lot of developers. For developers using the Gitflow workflow, things can be better though. One of the most controversial features is pull request building, which Bamboo doesn’t offer out of the box. CI tools like Travis offer integration for gitflow right away, including pull request building. But what if you want to stick with the Atlassian suite for all your tasks? How can we build pull requests and show their status in BitBucket?

In previous articles we answered some important questions already: why would you write tests in the first place? And, will it make you faster or slower?

Now we need to answer one other important question that should guide you in your daily quest to improve the quality of the code you deliver: when should you write a test?

In a previous article we answered the question "why you would write tests", or specifications for your software project. In this article we'll discuss costs and benefits of writing tests.

The world of "software testing" is quite a confusing one and it takes several years to understand what's going on and how to do things "right". In no particular order:

• Developers use different words for different types of tests, but also for different types of test doubles.
• Developers are looking to achieve widely varying goals by writing tests.
• Developers have divergent views on the cost of writing and maintaining a test suite.
• Developers don't agree on when to test software (before, during, after writing the code).

Last week I took part in the first ever Symfony Catalunya conference. The conference was a major event in Barcelona, attracting 400+ Symfony developers. It seems that most of the attendees were from Spain or Catalunya. I was surprised to see that some Dutch people were present too!

At Ibuildings we had been anticipating DPC 2016 for quite some time. Our internal DPC crew rebooted in January, starting with an update of the website and a mailing to announce that the Call for Papers was open again. We received about 350 proposals, which we narrowed down to 55 talks and 11 tutorials. It seems we made a good selection of talks, since many people complained that it was hard to pick the right talk to watch, given there are 5 parallel talks at any time...

Last week I've been attending, and speaking at, the NCrafts conference in Paris. It was a great conference, which had many talks to offer on wide-ranging topics that should make any software craftsman/craftswomen quite happy. Below you will find some remarks, summaries, notes, etc. related to the talks I visited on the first day of the conference.

So far we've told you about the schedule, the keynote speakers, the tutorial day and the Code Night of the Dutch PHP Conference.

Now we've got another announcement to make: this year, we'll have something new, something exciting, it's called: Speakers Workshop!