I've never been convinced about splitting developers into front and back end.
I see no reason why a decent developer can't build the front and the back end for each piece of new functionality. This removes all the communication issues.
I see no reason why a decent developer can't build the front and the back end for each piece of new functionality. This removes all the communication issues.
On a big, widely used consumer facing app however, front end developers really come into their own.
They have cross browser, cross device responsive design issues to contend with. Accessibility and graceful degredation. Performant JavaScript. They also need design skills.
Very few people have deep skills in back end and front end.
This is the cause of an awful lot of technical debt, and "big, widely used consumer facing app" is the natural habitat of large technical debts.
CSS and the DOM has it's own set of quirks and bits of required knowledge that good FE devs will all know quite well.
Turns out the back end (they were micro-services - even though the term hadn't been invented at that point) didn't have a call for "total number of users" so the front end code (this was server side HTML generation - 10+ years ago) was getting a list of every user in the system and iterating over all of them in chunks and counting.
I totally agree, but even if you have a front-end and back-end communicating well, sometimes the front-end developers throw too much over the wall to the back-end, like when the front-end "thinks it is more intuitive if the request looked like this" instead of something else that would be just as easy to create and would be much less work on the back-end. And I'm sure the opposite is true as well with back-end putting too much work on the front-end.
And, in the argument against a single full-stack developer being the solution to this problem, I've seen extremely talented full-stack developers create some terrible user interfaces, and some who created great user interfaces that would struggle to create adequately performant server-side services to back them.
Mono linguistic programmers don't tend to be very good, front end devs are almost by definition mono linguistic developers.
That doesn't sound right to me.
No-one in their right mind ever called flash developers genius coders, in fact they were (generally rightfully) regarded more as designers than developers and yet that's exactly the same niche front-end devs occupy today.
I've seen it more than once now, massive load of javascript built around the 'recommended' design patterns that as soon as you turn back into simple functions and throw a few if statements into to stop them initializing every page load, boom, massive page load gain.
You can be an expert on hoisting and this and ES6 and still suck at engineering, in fact I've seen it more than once in multiple languages, guys who knew entire language specs and yet couldn't code their way out of a paper bag.
There are 4 types of front end dev:
1. Designer who can throw together a few scripts
2. Inexperienced developer/designer
3. Developer who happens to have moved to javascript with basic design skills
4. Unicorn who's great at design and development
Everyone thinks they're 3 & 4s, in reality 95% of front end developers are 1 & 2s.
Half the things that get posted here that have dedicated front end devs are juddering, slow, scroll jacking monstrosities. Don't try and tell me that's not the present state of the front-end development, because we all know the reality is there's very few, actually good, front-end developers out there.
You're always going to have a bell curve of skill for every profession, not just devs or a specific subset of devs.
You can get a back-end developer to do front-end. He might lack the experience to deal with some gotchas or browser compatibility but it's nothing that can't be solved with a simple Google search.
A front-end developer doing back-end, on the other hand, might not work as well.
In my experience they often fail to come up with anything remotely modular on their own, write maintainable code, understand the design concepts of more "advanced" frameworks like Angular or doing anything different than copy-pasting some jQuery snippet they found on yahoo answers.
It's not that JavaScript forces you to write spaghetti code, it's just that until very recently it was mostly written by clueless morons that didn't know any better.
How can you write your front-end in something like Reagent if most of your staff get micro-strokes when being asked to type {{ }} instead of <%= %> in your new template system or go la la la can't hear you when you mention the merits of CSS preprocessors?
Fortunately this is all changing as the result of front-end these days getting more "mentally stimulating" thus capturing the interest of back-end developers (the ones that more often than not happen to have degrees).
disclaimer: anecdotal evidence etc
As a simple counter-example, Google requires all "front-end" developers to pass through the same algorithms interviews as backend developers.
Started with C++, then moved to PHP, looked at Ruby, picked up JavaScript, built some ASP.NET apps in C#, did some Unity programming, wrote a bunch of stuff in Java, then finally moved to full time JavaScript programming.
Why the hell do you think a front end dev is "by definition" mono linguistic? It makes no sense.
I disagree with this and am tired of the coupling between front-end development and design.
Especially on large apps, dedicated designers do the designer. Front-end developers implement.
I don't think we need FE Devs who are full on designers, but FE devs who are design 'aware' are, in my experience, much better.
Developers need as much a design ability as designers need engineering ability.
At Labs we practice pair programming with frequent (ideall daily) rotation, so skills tend to diffuse and stories tend to get looked at by people with different backgrounds.
There isn't any 'one true way' to do it. If a project is best built with a front end team and a back end team, then that's the best way to do it. If a project is best built with a team that does everything, that's the best way for that project.
Mind you, I would add that "This removes all the communication issues." is completely wrong. Having one person write the code for both sides compounds the communication issues, because it means no one other than that developer knows anything about the system. If communication is a problem then resolve that problem as soon as possible by writing good API documentation and sharing knowledge among the team, because if you don't you'll end up with an unmaintainable mess of code that's eventually sunk by the weight of technical debt.
Yes. A lot of back-end devs would rather chew glass than debug for four browsers, plus mobile devices.
These days front-end =/= Javascript[2] by a long shot (maybe yours is, but blame the person who made that decision for your project).
1. I don't know if that's still true. If it is, then I'm glad I no longer have to deal with MySQL.
2. GWT had strong-typing since forever. Not that I'm endorsing it, but it's still front end. I do recommend TypeScript
That's still true, as I recall. To avoid this nonsense, you need to change the sql_mode - either globally in the server config, or only within your session by issuing an SQL query.
Documentation: https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmod...
Second: Good developers are hard to find. Backend requires both good CS background (algorithms, security) as well as development skills. Frontend requires some feeling for design and can tolerate poor development skills.
Second: Don't insult front-end developers. I do both back and front, and I find front-end to require much more skill. Nobody notices if a backend feels slightly off, but it's very obvious when an interaction was built by someone who isn't a great front-end programmer. Both sides are necessary and difficult in their own way; they just require different skillsets.
Oh you'll notice it in three months, when you have to write that new feature.
Actually, that refers to adding more resources to _an already late project_. It explicitly mentions that starting out with more resources can speed up development.
In saying that, 9 women can't make a baby in one month.
I have, it's a brilliant book. Helped me greatly during my career. However it's about scaling an already broken (and late) project in a very naive way.
Luckily we've learnt a lot since then - and it turns out that decomposing the problem into 4-6 person chucks and optimizing for minimum dependencies is a good strategy to close-to-linear scalability :)
If that's all you remember of it, you really need to reread it (and I find myself mildly skeptical that you did in the first place - although it could very well be that it's been long enough you thought those ideas were elsewhere). The title - and Brooks' Law - is about that, but the book covers a whole lot more. Including discussions of approaches to decomposing problems into <10 person chunks and optimizing for minimum dependencies.
It seems you're assuming front end developers are usually designers with some coding skills, or developers with some design skills, and neither is the case. A fairly complex app will most definitely have designers and developers in their front end team.
I think the main reason for the separation is domain knowledge. You may have a lot of experience designing real time APIs, but no experience with web technologies. I've worked with a lot of good developers that still don't get HTTP status codes or the basic principles of REST APIs, but they're good developers nevertheless. And perhaps that's why the role of the full stack developer has become now more popular.
Native development - and cutting edge web-based development - is a different beast. You start needing knowledge of threading, messaging, various architectural patterns etc.
I'm actually recruiting for such a developer now - someone who wants to be top specialized front-end developer. They're just extremely hard to find (if you're interested in working on a complex SPA and are in, or want to move to NL, drop me a line! You don't need to speak dutch!).
You're right about domain knowledge: there is just too much that you need to know to be able to be an effective "full stack" developer for anything approaching a complex system.
Whether backend vs frontend is the right "seam" for division of labor depends entirely on the complexity of the systems at play, as opposed to some arbitrary generalization of all backends and frontends as you seem to be making here.