{"id":533,"date":"2020-10-21T11:56:34","date_gmt":"2020-10-21T11:56:34","guid":{"rendered":"https:\/\/thenextweb.com\/?p=1324653"},"modified":"2020-10-21T11:56:34","modified_gmt":"2020-10-21T11:56:34","slug":"why-over-specialized-developers-are-the-root-of-all-evil","status":"publish","type":"post","link":"https:\/\/www.londonchiropracter.com\/?p=533","title":{"rendered":"Why over-specialized developers are the root of all evil"},"content":{"rendered":"\n

This article<\/a> was originally published on <\/span><\/i>.cult<\/span><\/i><\/a> by Fagner Brack. .<\/span><\/i>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.<\/span><\/i><\/p>\n

<\/span><\/i>Has something like this ever happened to you?<\/p>\n

You go on a website, and there\u2019s 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.<\/p>\n

\n

The software we use today doesn\u2019t work<\/a>; many of the causes boil down to specialization.<\/i><\/p>\n<\/blockquote>\n

One day, my colleague was refactoring the Big Ball of Mud<\/a> 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 \u201cproof of concept\u201d. After he showcased the POC, the team was impressed. They liked the outcome and agreed that the changes should go to production.<\/p>\n

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.<\/p>\n

Everything went fine as the \u201cDevOps Team\u201d 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.<\/p>\n

So what caused the breakage?<\/p>\n

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\u2019t observe the problem in any of the end-to-end tests, as the authentication mechanism for the test accounts didn\u2019t require those tokens to be there.<\/p>\n

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.<\/p>\n

\n

One of the three front-end clients depended upon a specific string format of a specific server for their login mechanism to work.<\/p>\n<\/blockquote>\n

The company had organized the teams by technology. Each of them was responsible for one client. There was the \u201ciOS Team\u201d owning the iOS app, the \u201cAndroid Team\u201d owning the Android app, the \u201cWeb Team\u201d owning the Web app, and the \u201cBack End Team\u201d 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.<\/p>\n

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\u2019t 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.<\/p>\n

Product development worked like this: the feature started from the User Interface \u2014 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.<\/p>\n

The communication cost for the development of a single feature was so high that each client ended up<\/a> 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.<\/p>\n

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<\/a> instead of incrementally<\/a>.<\/p>\n

It was a tragedy waiting to happen.<\/p>\n

\n

The segregation of people with \u201cFront-End\u201d skills from people with \u201cBack-End\u201d skills had a significant impact on the communication between teams.<\/p>\n<\/blockquote>\n

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 \u201cpart\u201d of the job quickly and efficiently. The \u201cother team\u201d was always the problem.<\/p>\n

The most straightforward solution to this is to consider the need for \u201cThe Architect\u201d \u2014 that person sitting in the Ivory Tower dictating what should and should not be. Be careful! \u201cThe Architect\u201d may be the right pill to treat the symptom, but it won\u2019t cure the disease. It\u2019s everyone\u2019s job to understand the big picture. How do you expect to work with a purpose if you don\u2019t understand what that overall purpose is?<\/p>\n

\n

\u201cThe Architect\u201d, 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<\/a>.<\/p>\n<\/blockquote>\n

This story happened within a major financial institution that was too big to fail. It didn\u2019t 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 \u2014 technological stagnation at its best.<\/p>\n

They were the lucky ones. Their software was generating enough revenue to outweigh all the costs for the design of new features.<\/p>\n

However, your company probably won\u2019t be as lucky as them.<\/p>\n

Nowadays, it\u2019s prevalent for developers to follow the technical path of major successful organizations. However, that doesn\u2019t 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.<\/p>\n

\n

If the software works and the company is too big to fail, then it\u2019s hard to push any change. However, if you\u2019re not too big to fail, then you better act. Fast.<\/p>\n<\/blockquote>\n

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\u2019t work for an intellectually demanding task like software development.<\/p>\n

Nowadays, specialization seems to be the root of the most significant communication problems among software teams and their shift in culture. It doesn\u2019t matter if you\u2019re the best \u201ciOS\u201d developer or \u201cReact\u201d developer in the world. If you can\u2019t 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\u2019s harder to justify the value you\u2019re bringing into the table. Pushing work over the wall to \u201cthe other team\u201d doesn\u2019t work, you have to own it to the end.<\/p>\n

That doesn\u2019t mean everyone should be the \u201cJack of all trades, master of none\u201d.<\/p>\n

Here\u2019s the trick:<\/p>\n

The best programmers I\u2019ve 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\u2019s when they invest the time to research and look up the details of how to apply them.<\/p>\n

\n

It\u2019s impossible to know everything; you optimize to learn what the options are so that you can dig deeper when necessary.<\/p>\n<\/blockquote>\n

So what are you going to do?<\/p>\n

Are you going to follow the trend of big companies and hire that great \u201cReact Developer\u201d which is also a great \u201cC# Developer\u201d and \u201cCS Guru\u201d? Or are you going to work towards hiring that \u201cSoftware Developer\u201d who regardless of the programming language, understands the basics about architecture, software design, and other areas?<\/p>\n

It\u2019s 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<\/a>. Specialization creates silos; broad knowledge-sharing creates opportunities.<\/p>\n

Don\u2019t be like that tribe<\/a>, waiting for the planes that\u2019ll never come.<\/p>\n

You\u2019ll be waiting for a long, long time.<\/p>\n

<\/figure>\n<\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

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…<\/p>\n","protected":false},"author":1,"featured_media":534,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/533"}],"collection":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=533"}],"version-history":[{"count":0,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/533\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/media\/534"}],"wp:attachment":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=533"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=533"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=533"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}