Case 06

Stepping outside my scope to understand the whole system

Context

April Technologies is the IT arm of April, a French insurance group. Second time on this project: I had already worked on it in 2013–2014, on an assignment at CGI, for April. This time, on assignment through Modis, to build the frontend of an application in Symfony 1.3. The backend was in Java and exposed SOAP APIs to us. My scope: the UI that displays the data returned by the services. In practice, layout work.

The problem

No production problem; a comprehension problem. Confined to displaying whatever a service sent me, I did not know where the data came from, how it was built, or why it arrived in that shape. Hard to build a good frontend without understanding the backend — and, honestly, hard to stay interested.

What I decided

It happened in two stages. First for debugging: when I had an error on the frontend, I went to read the Java to find out whether it came from me or from the service, and to be able to tell a Java developer “this doesn’t work, for this reason” instead of sending back a vague ticket. I was not starting from zero: I had done Java years earlier, for cryptography that PHP could not do at the time.

Then because I was moving faster than what had been planned for me. I proposed taking features end to end: the frontend, and the backend that goes with it — creating the field in the Java entity, hence in the database, adding the backend validations, within the insurance business context.

Outcome

What it shows

I do not stay in the box I was given when understanding the rest makes my work better. I go and look at the backend when I do the frontend. I switch languages when the problem calls for it — Java for cryptography, Java to understand an API — and tomorrow another language on an assignment migrating away from PHP. The language is a tool; what matters is understanding the whole system.