All About Agile | Agile Development Made Easy


Software Development: Specialize or Generalize?

by Michael Dubakov, 11 January 2013 | The Agile Blogosphere

This content is syndicated from Edge of Chaos | Agile Development Blog by Michael Dubakov. To view the original post in full, click here.

Now here’s a good topic for discussion. Many years ago we were hiring software developers as such. For the most part, they were good at their job, but not all of them.  Me, personally, and all my teammates back from these times – we were writing in any language. Something needs to be done in .NET? There we go. Any HTML work? No problem (well, the HTML work was mostly for me). Shoot something in javascript? Done. I’m not talking about the quality of these solutions, not yet.

Then, we became set apart from each other:  here’s the JS team, and they give zero consideration to the server-side tasks. These guys are .NET guys, and God forbid if they lay their hands on the client-side (with rare exceptions). This distinction projects into hiring as well: here’s a .NET, a .JS and an iOS position. It manifested itself in particular as we got down to tp3, putting the clear boundaries between various areas of responsibility. The UI is done in .JS and .JS only, everything communicates with REST API, the core team negotiates the query/response format with the .JS team, and off we go. This is a nice way to start a new project. Each team is busy with their part: they design architecture and do the refactoring as they aspire to perfection within their boundaries.

However, there comes a time when the teams are almost done with the architecture, but there’s a flurry of horizontal application-specific issues.  It somehow turns out that there’re tons of the UI related tasks, and few server-side tasks. That’s when specialization delivers the heaviest blow. The teams are not aligned, there’re twice as less developers in the UI team as compared to the .NET team.   As a result, a half of the core team developers hang around nagging for new tasks, and one has to assign them to not so important jobs. On the contrary, the UI team is permanently slammed.

My opinion is simple: there’s no ultimate specialization. Sure thing, someone prefers one technology over another, and works with it most of the time. But a classy developer is able to adapt to a new ecosystem quickly and write in any programming language efficiently enough. The 80/20 rule of thumb might well be in effect here.  You’re focused on your core competencies, at the same time reaching out to the new areas.

From the company’s standpoint, it’s very cool when someone can create a feature in its entirety. There’re less delays, the feature passes all the developments stages faster, there’re less discussions and handovers. One can truly stay focused on the tasks that are important at this very moment, and not shop for some work of a lower priority.

From the developer’s standpoint, it’s not as simple as that. I’ve never had any problems or issues doing something by myself.  For some reasons, it is a big problem for some people. Yes, at the beginning you’re not likely to come up with perfect solutions. Yes, there will be some naive mistakes. But, in my opinion, a great software developer can deliver sensible solutions even in a fairly unknown environment.
Next, it’s about personal involvement. Many people hold .JS for HELL. However, if the framework is done, as well as HTML, it doesn’t look that bad. Some interesting things can be accomplished with .JS as well.

Why I liked to do a feature all by myself? It’s about the great feeling that I did it on my own, that’s why. This feeling means a lot to me. How about you?

To sum up, we will now resume hiring classy software developers, the ones that can create the entire feature from start to end, despite the technologies, and have nothing against that.

Translated from Russian by Olga Kouzina

Home



Leave a Reply

What is 7 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)