Today I was reminded how useful collaboration is when it comes to programming abstract concepts. I had been given a task/project and because it was so abstract in nature and the requirements weren't all accounted for - I had to invent requirements to what 'best fits' the problem were trying to solve. so there us a element of uncertainty in what the solution needs to solve and what makes the solution solve the problem. So if you approach a task as simply creating a solution, in our situation, you will never create a solution because you have not the requirement of the solution, thus you need to to that first. It can be argued that requirement specifications should be provided before hand so that a solution to meet those requirements can be created. however, if you are the designer, implementer - the onus is on you to understand the need, find the requirements and implement the solution. This is beneficial in as much as you don't implement blindly based on requirements/constraints that you don't know why exist. The problem is how long it takes. Building an engine based in a blueprint is much easier than building it, not knowing where all the parts are in your garage or worse, knowing your parts have been stolen and now have to make them in order to build the engine. Not the greatest example but you get the picture - it takes longer and is more complex. So collaboration helps figure out what requirements there are or should be for solution to solve a problem. it's a lot of work primarily because no one knows the solution, all the things it needs to solve etc... so you need help.

Talking, discussion takes the burden off having to know everything about something you know nothing or little about.