Crafting Code Across the Stack: 3 Benefits of Cross-Technology EngineeringPosted: July 7, 2011 | Author: yeeguy | Filed under: consumer internet, engineering, product management, social apps, startups | Tags: consumer internet, engineering, startups |8 Comments
One of the engineers in my startup asked some thought-provoking questions in a hallway conversation today:
Should engineers own end-to-end implementation of features that cut across multiple layers of our technology stack? Or should engineers focus/specialize on specific layers of the stack and collaborate with each other to develop each feature?
I’ve repeatedly observed that small teams of developers run circles around large teams in every company I’ve ever been in. [Caveat: I focus on consumer internet software, so my observations will be biased towards that industry.] I have a strong preference for company cultures that encourage individual engineers to develop as much of a featureset as they can on their own. If there’s a front-end user interface to be created as well as a backend API required to support a particular feature, I’d like to see the same engineer coding it all. Obviously this isn’t always possible for either technical or personnel constraints, but it is the ideal in my mind.
Seeing that reminded me of the three main benefits of getting engineers to own entire featuresets, even (or maybe especially) if they cut across multiple technologies…
When an individual engineer works on a feature that they know is going to impact large numbers of users, they viscerally feel the huge contribution they’re making to their company (and society!). Nothing is more motivating than feeling like your work really makes a difference.
An engineer who really understands an entire featureset front-t0-back is able to grok critical dependencies between technology layers more effectively than a team of multiple individuals. I assert that the ability to see the whole picture enables the single engineer to more effectively write test cases, identify likely breaking points, and ultimately deliver higher overall quality code that is defensively coded against future commits.
This is a key advantage for individual engineers: the engineer who designed and coded an entire featureset on their own will be more likely and much faster to modify/iterate their designs when presented with market feedback from real consumers. In contrast, a team of engineers who each only coded parts of a feature (and therefore relied on some other person, usually a project manager or a product manager, to provide a holistic view and integration guidance) will be much slower to collectively process market feedback and iterate.
Now, this may all be much easier said than done… For one thing, it’s hard enough to recruit great engineers in any given technical area, much less a team of cross-technology superstars. And in practice, there are significant friction points to the lone-ranger style of development. E.g., if every engineer is a gun slinger they may unwittingly produce a lot of conflicting or redundant code that at some point needs to refactored. Furthermore, even if an engineer is capable of contributing code across many different levels of a tech stack, that doesn’t mean they will always *want* to do so…
Have you ever worked in a company that had a policy of “single engineer owns an entire feature”?
I have worked in such a company and the results were strong, but the quality of the code sometimes suffered since individual components within a feature didn’t have a specific owner.
That’s pretty much what I’m doing at my present company. I think there are a lot of benefits if you’re doing proprietary work (for example, I use .NET, but most of the things I am doing are not out of the box…things like custom serializers, for example), but it can make project management and tracking more difficult especially if you have a growing sales team making increasing promises!
I am in this exact situation now, so it’s interesting to see a blog post on it. I work at a company with only about 250 employees and for the last 6 – 8 months I’ve been the one and only developer on our systems. We recently added one more developer but he is junior level and still learning. I have handled the from scratch design of a custom ERP system. This means that I have designed the application architecture, created the SSIS jobs that move data from various other production systems to our new database, created the data model for the database, designed the UI for each piece of the application, and am writing all of the application logic. It is a lot of work but I like having control of all aspects of the system. The new developer definitely is nice since sometimes I do feel a little overwhelmed, but overall I’d like to think that it’s going well all things considered.
Yep, I am big believer of developing features end to end, rather than layers of technology. I practice this very vehemently with my own team (in the small company I co-founded).
Some benefits we see –
1. People know functionality and use cases extremely well – in fact everyone from developer to tester focusses on simplifying the user flow as much as possible
2. Strong accountability and sense of responsibility – a feature either works, or it doesn’t. There is no interface layer to worry about.
3. Strong sense of ownership – there is no architect to tell them exactly what classes to create and how to design – the developers own their functionalities, and only have to adhere to some good practices.
4. Everyone learns a lot – leads to good job satisfaction
There is one obstacle to the single man approach:
He cannot knew all the tricks a SQL buff knows…
He cannot knew all the browser quirks …
He cannot knew the complete language framework…
He cannot knew all the user whishes…
all together in a single person.
This simply cannot be handled by a single person. Perhaps for a small project or with a genius programmer without social life imprisoned in a server room.
But with normal people an the propesed approach the project will always be on low tech level.
This is the same as you would say:
We at Toyota have all people building a car from A to Z eliminating the assembly line resulting in a “Strong sense of ownership” … gimme a break!
[…] 10. Преимущества кросс-инженерных технологий […]
I’m voting ‘YES’ for multi-stack developing.
An age ago I was toiling with OSI and interconnecting between 5 main platforms and after this, we were targeting database and systems software across 9 platforms, 4 external platforms like Unix and Windows.
That pretty much sums up why we almost have a mono-culture of systems. When we had may be 10 viable performing operating platforms in the 1990-s we now have two (Windows and Linux) with some platforms by Apple. Of course we could add Java and Chrome O/S.
Ramble over /w
I am a definite YES.
I am unsure if there is any other way to do things.
The alternative on any large multi-tier system is massive specification document, which no one ever reads and definetely no one ever really understands properly.
– the back-end implementation will be done by multiple people according to the UML diagrams.
– Tests might be written if you are lucky.
– and now you have to integrate into this black box system without the ability to debug any erros
The upshot is a massive budget requirement, lots of meetings to discuss interfaces, and hair pulling trying to identify problems through the logs.
The alternative is 1 man building all tiers of a system for 1 piece of functionality.
You know what you need, so you only build that. (properly agile…)
You know how it was built so you can debug it.
You built it, so you have admin rights already.
You built it, so no meetings to discuss it.
Much smaller budget, and it actually gets delivered.
Ok, the problem is finding an engineer capable of doing it all.
But come on, we have been building these system for nearly 2 decades, there are enough of us out there with cross platform/tier competance that we can do it. And we can teach the others a few things on the way.
If you are a master of your art, and have the years (decade+) of experience in every system required then it is actually easier to build it yourself than explain it. If you try to build the whole system like this yourself, you will fail. So just take a vertical slice of functionality across all the tiers, that way it stays manageable.