5 ms·
After completing my CS master's degree, I was hired by my advisor as a full-time software developer. My job was to coordinate the efforts of the students contr
by DoofusOfDeath 10y ago
After completing my CS master's degree, I was hired by my advisor as a full-time software developer. My job was to coordinate the efforts of the students contributing to his main project, keeping everything moving forward.
For that job, I found that keeping things asynch was crucial. But so was keeping things lock-free.
My basic premise was to never assume that any grad student would get any particular task done. So I tried to create an environment where any time they had a useful contribution, it could be merged into the main code base. But to never put one student at the mercy of another.
I think that worked pretty well.
- deleted 10y ago[deleted]
- Inthenameofmine 10y agoThat sounds very interesting. Could you go into more depth what techniques you exactly used?
- huherto 10y agoGeneralizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.
- nradov 10y agoYes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams. In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.
- brilliantcode 10y agoThis is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disciplinary communication shitshow. I wonder if there is an official name for this feature teams model or more guide on how to implement it.
- nradov 10y agoScaled Agile Framework features and components: http://www.scaledagileframework.com/features-and-components/ http://www.scaledagileframework.com/features-and-components/ "Scaling with Feature vs. Component Teams" by Ken Rubin: http://www.innolution.com/resources/presentations/svaln-2015-scaling-with-feature-vs.-component-teams http://www.innolution.com/resources/presentations/svaln-2015...
- brilliantcode 10y agoThis is gold. Thank you for posting that.
- pcsanwald 10y agoThe more general term for these two structures are Functional vs Divisional structures. In the case of software engineering, a feature based team is a functional structure, and a "database team" (or "API team", or any other specific technical concern) is a divisional structure.
- brilliantcode 10y agoso why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?
- vas123 10y agosounds a bit like functional programming and minimizing side effects