Thisarticlewas originally published on.cultby Fagner Brack.
.cult is a Berlin-based community platform for developers.
Has something like this ever happened to you?
The software we use todaydoesnt work; many of the causes boil down tospecialization.
After he showcased the POC, the team was impressed.
They liked the outcome and agreed that the changes should go to production.
The software of his company was serving thousands of users simultaneously around the clock.
Everything went fine as the DevOps Team deployed the back-end change to production.
However, minutes later, customers were unable to login to the iOS app.
The Call Center was bombarded with a significant number of angry customers.
40% off TNW Conference!
The back-end API and the mobile front-end had an implicit contract.
At runtime, clients would replace those variables with some data they had cached.
There was no documentation for that functionality.
The string format was only consumed by the iOS app, not by any of the other API clients.
The company had organized the teams by technology.
Each of them was responsible for one client.
Many of the artefacts each of those teams produced had repeated business logic.
The company had multiple teams responsible for implementing similar UI functionality without clear boundaries of who owns what.
Each developer was very comfortable with their stack, unwilling to discuss ideas with developers working with other technologies.
The back-end service ended up becoming a database over HTTP where every system had a direct dependency on it.
The effort to ship features in that company was significantly high; psychological safety was deficient.
Everyone involved had all the incentives to produce software inbig batchesinstead ofincrementally.
It was a tragedy waiting to happen.
Everybody was delivering their part of the job quickly and efficiently.
The other team was always the problem.
The Architect may be the right pill to treat the symptom, but it wont cure the disease.
Its everyones job to understand the big picture.
How do you expect to work with a purpose if you dont understand what that overall purpose is?
The Architect, if you must, should be a facilitator rather than a dictator.
They should mentor the other developers on how to spot the big picture toask the right questions.
This story happened within a major financial institution that was too big to fail.
They were the lucky ones.
Their software was generating enough revenue to outweigh all the costs for the design of new features.
However, your company probably wont be as lucky as them.
Nowadays, its prevalent for developers to follow the technical path of major successful organizations.
However, that doesnt mean their path also works for you.
However, if youre not too big to fail, then you better act.
The idea of specialization comes from the traditional mindset of a manual production line.
It doesnt matter if youre the best iOS developer or React developer in the world.
That doesnt mean everyone should be the Jack of all trades, master of none.
Heres the trick:
The best programmers Ive met prioritize learning techniques, not technologies.
So what are you going to do?
Specialization creates silos; broad knowledge-sharing creates opportunities.
Dont be likethat tribe, waiting for the planes thatll never come.
Youll be waiting for a long, long time.
Story by.cult
.cult by Honeypot is a Berlin-based community platform for developers.
