4 ms·

What I'm insinuating here is that the environment is always more complicated than meets the eye. Granted, project complexity is as disparate as they're randomly

by pp19dd 12y ago

What I'm insinuating here is that the environment is always more complicated than meets the eye. Granted, project complexity is as disparate as they're randomly different from each other. * Would you bring bricklayers to the design meeting? No. Just the foreman. * Would you bring all programmers to the design meeting? No. Just the lead developer. Yes, ideally you'd have all the programmers in the room, but more of them you introduce, you increase the communication overhead. And some projects involve dozens to hundreds to thousands of programmers and are complicated enough to not be able to bring everyone to the discussion table. So what you have to do is use bricklayer programmers- trust them to do a single task right (warehouse uploaded photos, talk to APIs) but recognize their limits. I'm not faulting neither bricklayers nor programmers, but defining their borders more concisely.

marcus_holmes 12y ago
yeah, I've worked on some big projects in my time, 100's of programmers. And all of them would have been done better by splitting the project up into smaller chunks and doing them in series. I've never met a business problem in my 30+ years doing commercial IT that couldn't be split up into smaller problems with smaller solutions, but there seems to be a bias towards large teams and complex solutions in commercial IT. I don't know what causes this (I suspect management ego or consultancy fees, the cause of most commercial IT problems), but it's a real problem. The vast majority of these huge projects fail, go massively over-budget, precisely because they're being managed wrong. Programming is fundamentally not like bricklaying, because it's creative not deterministic. Better, more detailed and more complete specs won't make more successful projects. If you have too many programmers to bring them into the room when you're specifying the problem, then your project team is too big. The answer is not to exclude programmers and create more detailed specs, because programmers working to a spec like that won't write good code. I know, I've been there. One project in particular stands out. We had detailed specs for a range (a few hundred) of middle-layer business routines. I received a function spec, wrote the function, wrote a few tests that the function did what it should do, ticked the box. Rinse and repeat for months. There were people working in a similar fashion on the front end and database layer. The system went over-budget, never worked, and was finally scrapped. It's not hard to see why, when the entire system was being written in this fashion. Programming is not like bricklaying. If you think about it for 5 minutes you'll see that "bringing more programmers into the room increases communication overhead" implies that there is some information that is required to be passed from the customer to the programmer. The solution to this problem is obviously not to exclude the programmer and reduce the information passed to them, because that will lead to inferior code because the programmer is missing information. Instead reduce the amount of information the team is dealing with by segmenting the problem better.

by pp19dd 12y ago

marcus_holmes 12y ago

yeah, I've worked on some big projects in my time, 100's of programmers. And all of them would have been done better by splitting the project up into smaller chunks and doing them in series. I've never met a business problem in my 30+ years doing commercial IT that couldn't be split up into smaller problems with smaller solutions, but there seems to be a bias towards large teams and complex solutions in commercial IT. I don't know what causes this (I suspect management ego or consultancy fees, the cause of most commercial IT problems), but it's a real problem. The vast majority of these huge projects fail, go massively over-budget, precisely because they're being managed wrong. Programming is fundamentally not like bricklaying, because it's creative not deterministic. Better, more detailed and more complete specs won't make more successful projects. If you have too many programmers to bring them into the room when you're specifying the problem, then your project team is too big. The answer is not to exclude programmers and create more detailed specs, because programmers working to a spec like that won't write good code. I know, I've been there. One project in particular stands out. We had detailed specs for a range (a few hundred) of middle-layer business routines. I received a function spec, wrote the function, wrote a few tests that the function did what it should do, ticked the box. Rinse and repeat for months. There were people working in a similar fashion on the front end and database layer. The system went over-budget, never worked, and was finally scrapped. It's not hard to see why, when the entire system was being written in this fashion. Programming is not like bricklaying. If you think about it for 5 minutes you'll see that "bringing more programmers into the room increases communication overhead" implies that there is some information that is required to be passed from the customer to the programmer. The solution to this problem is obviously not to exclude the programmer and reduce the information passed to them, because that will lead to inferior code because the programmer is missing information. Instead reduce the amount of information the team is dealing with by segmenting the problem better.