Taking too long? Close loading screen.
Connect with us

Tech

Why over-specialized developers are the root of all evil

Published

on

This article was originally published on .cult by Fagner Brack. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the world.

Has something like this ever happened to you?

You go on a website, and there’s a spinner which loads forever, or an empty screen that forces you to stare, a disabled button that never enables, or even a page that drains your battery only for the phone to die in the most inconvenient circumstances.

The software we use today doesn’t work; many of the causes boil down to specialization.

One day, my colleague was refactoring the Big Ball of Mud inside of one of the many API services of their company. Initially, the members of his team were very defensive regarding his approach, so he paired with another colleague to craft a “proof of concept”. 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. There were 3 kinds of UI front-ends: the iOS app, the Web app, and the Android app.

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. Everybody was confused, but there were no doubts about what was the cause: the refactoring which had deployed was locking customers out.

So what caused the breakage?

The back-end API and the mobile front-end had an implicit contract. The back-end should return strings in a specific format so that the iOS app would interpret individual tokens from that format as variables. At runtime, clients would replace those variables with some data they had cached. The developers couldn’t observe the problem in any of the end-to-end tests, as the authentication mechanism for the test accounts didn’t require those tokens to be there.

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.

One of the three front-end clients depended upon a specific string format of a specific server for their login mechanism to work.

The company had organized the teams by technology. Each of them was responsible for one client. There was the “iOS Team” owning the iOS app, the “Android Team” owning the Android app, the “Web Team” owning the Web app, and the “Back End Team” owning the API service. Many of the artefacts each of those teams produced had repeated business logic. That means changes in one application would require a developer to touch three to five different repositories to get the work done.

Thanks to the developer turnover rate in the department and the lack of documentation, the team who owned the relevant back-end service had no idea the iOS team was consuming such string format in production. The only way they found out they didn’t have control of their software was after refactoring a critical part of the service, deploying it to production and locking customers out of their accounts.

Product development worked like this: the feature started from the User Interface — web or mobile, and then each client had the responsibility to change as many services as they needed to get their work done. 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 communication cost for the development of a single feature was so high that each client ended up reinventing their own business rules within their apps. 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 in big batches instead of incrementally.

It was a tragedy waiting to happen.

The segregation of people with “Front-End” skills from people with “Back-End” skills had a significant impact on the communication between teams.

Unless you looked from the outside, it was hard to see how the skill segregation was slowing down the software development process. Everybody was delivering their “part” of the job quickly and efficiently. The “other team” was always the problem.

The most straightforward solution to this is to consider the need for “The Architect” — that person sitting in the Ivory Tower dictating what should and should not be. Be careful! “The Architect” may be the right pill to treat the symptom, but it won’t cure the disease. It’s everyone’s job to understand the big picture. How do you expect to work with a purpose if you don’t 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 to ask the right questions.

This story happened within a major financial institution that was too big to fail. It didn’t matter how slow they were: as long as the existing system continued producing millions of dollars of revenue per hour, there was no incentive for them to change — technological stagnation at its best.

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 won’t be as lucky as them.

Nowadays, it’s prevalent for developers to follow the technical path of major successful organizations. However, that doesn’t mean their path also works for you. There are many reasons why major tech companies have reached their state of success, many of them unrelated to technical excellence.

If the software works and the company is too big to fail, then it’s hard to push any change. However, if you’re not too big to fail, then you better act. Fast.

The idea of specialization comes from the traditional mindset of a manual production line. There are people positioned at different stages of the ramp, each responsible for constructing different parts of the product. Maybe that works for a production line, but it doesn’t work for an intellectually demanding task like software development.

Nowadays, specialization seems to be the root of the most significant communication problems among software teams and their shift in culture. It doesn’t matter if you’re the best “iOS” developer or “React” developer in the world. If you can’t solve a problem that spans across multiple stacks, either by doing it yourself or pairing with those who know more than you in that area, then it’s harder to justify the value you’re bringing into the table. Pushing work over the wall to “the other team” doesn’t work, you have to own it to the end.

That doesn’t mean everyone should be the “Jack of all trades, master of none”.

Here’s the trick:

The best programmers I’ve met prioritize learning techniques, not technologies. They learn the trade-off of those techniques even before they understand the details of how to apply them using the tools they have. When they face a situation where one of those techniques makes sense, that’s when they invest the time to research and look up the details of how to apply them.

It’s impossible to know everything; you optimize to learn what the options are so that you can dig deeper when necessary.

So what are you going to do?

Are you going to follow the trend of big companies and hire that great “React Developer” which is also a great “C# Developer” and “CS Guru”? Or are you going to work towards hiring that “Software Developer” who regardless of the programming language, understands the basics about architecture, software design, and other areas?

It’s time to look at software as an essential part of our lives and start to apply things that work, not to repeat the same thing over and over again, expecting different results. Specialization creates silos; broad knowledge-sharing creates opportunities.

Don’t be like that tribe, waiting for the planes that’ll never come.

You’ll be waiting for a long, long time.

Source

Continue Reading
Advertisement
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Tech

Charge Your Phone Wirelessly With 50% off a Multifunctional LED Lamp

Published

on

Best Tech DealsBest Tech DealsThe best tech deals from around the web, updated daily.

White Wireless Charge Lamp | $18 | Amazon | Clip coupon + code ABC88699
Black Wireless Charger Lamp | $20 | Amazon | Promo code ABC88699

When you’re ready to turn in for the night, you don’t want to forget to charge your phone— especially if your mobile device doubles as your alarm clock.

With this wireless charger lamp, you can make this crucial step of your nightly routine even easier by just setting your phone on the wireless charging pad and… well, that’s all there is to it!

Advertisement

Other functions include multiple lighting modes as well as a sleep timer option for auto shut-off of the light after 30 or 60 minutes.

This lamp can be yours in white for $18 if you clip the coupon on Amazon (it’s below the original $40 price) and add promo code ABC88699 at checkout.

You can snag the black version for $20 using the same code—no coupon though, sorry.

Don’t sleep on this deal! Who knows how long stock or the coupon code will last?

Advertisement


Source

Continue Reading

Tech

Keep That Hotdish Hot With 65% Off a Luncia Casserole Carrier, Only $11 With Promo Code

Published

on

Best Home DealsBest Home DealsThe best home, kitchen, smart home, and automotive deals from around the web, updated daily.

Luncia Double-Decker Dish Carrier | $11 | Amazon | Promo code SDDU9S7F

It has been a long time since the days we could safely have a potluck or other gatherings, but we have a fantastic deal perfect for once those times return. These double-decker Luncia dish carriers can be had for 65% off when you add promo code SDDU9S7F at checkout and clip the coupon on the site (it’s just below the price). These holders fit 9″x 13″ sized baking dishes.

Advertisement

That means you can insulate and keep two dishes of food warm for only $11 instead of $30. What’s more, your Luncia carrier will arrive by Christmas if you order today as a Prime member.

Just add promo code SDDU9S7F and clip the 5% off coupon to bring the price down to $11 for the blue or the grey option.

Advertisement

Grab this offer while it’s still around!


Source

Continue Reading

Tech

Conquer Your Pup’s Dander and Fur With $700 Off a Cobalt or Charcoal Bobsweep PetHair Plus Robot Vacuum

Published

on

Best Home DealsBest Home DealsThe best home, kitchen, smart home, and automotive deals from around the web, updated daily.

Bobsweep PetHair Plus Robot Vacuum & Mop (Cobalt) | $200 | Best Buy

Bobsweep PetHair Plus Robot Vacuum & Mop (Charcoal) | $200 | Best Buy

Allergies can be bad enough as the seasons change. Don’t let pet hair and dander add to that by vacuuming it up early and often. That chore is easier said than done— unless you have a robot vacuum to do the work for you. This lovely bright cobalt Bobsweep PetHair Plus robot vacuum and mop, only $200 today at Best Buy seems like an ideal option. That’s a whopping $700 off, by the way.

Advertisement

You can get the same deal for the charcoal version of the robot vac, too. This model is not only specially made for picking up pet hair, it self docks and charges when it’s finished with the work.

It also comes with a mop attachment, so it can take care of those kitchen floors for you as well. Grab it while it’s still available for this fantastic price!

Advertisement


Source

Continue Reading

Trending