|
The most important realization I had this year is that the biggest problem in software development (from the tech perspective) is not about programming, but about getting people to talk and cooperate. I don't think you can successfully break up programming tasks for junior devs, who can then independently implement them. It has two problems: 1) You either get a lot of code with incompatible ideas, or you do a lot of coaching. 2) The junior devs are not learning as much as they could. So you should not try to do this on your own, but rather involve the people who will be implementing the project in the process. You can still design the system in your head in advance, but I think the best approach is to then discuss it with the people on the project and come up with the final version together. Maybe somebody will have a better idea, or just tell you something you missed. As you go deeper and deeper, you will keep discovering problems on the lower levels. Some things will remain unknown or require experimentation, but for most you can come up with a solution. I think it's very valuable if everybody on the team understands the big picture. If the application has a few completely separate modules, then you can do the lower level design in different groups, but it's still useful if the task breakdown comes from the people who will be working on the code. Doing it in a meeting, rather than a write up and review process, gives them instant feedback. Regarding the task breakdown itself, I try to think of how I'd implement all of the code myself. That means thinking about what data comes though the system and where it can be used to set code boundaries, which parts are more important and which can wait, what would be the smallest presentable version and how can I move it further after it's done, do I have some non-code dependencies (business decisions, dealing with external services). I like to draw diagrams (mainly the data flow). Sometimes tasks are simply large and you can't do much about that, but you can at least some milestones for them. This makes sense to me in a smaller company when building some web application, probably does not make sense in a different situation. (Sorry for a long comment.) |
Completely agree. This will allow the person working on this component to make trade-offs as necessary. They may also catch things that you didn't think of when building the system ie: Separate individuals working on subcomponent A and subcomponent B may realize they can share a lot of logic/configuration - no need to duplicate it.