3 ms·

I'd have to argue that an architectural drawing is not very detailed. And even if it is, the builder takes plenty of latitude in constructing the building. Fo

by pp19dd 12y ago

I'd have to argue that an architectural drawing is not very detailed. And even if it is, the builder takes plenty of latitude in constructing the building. For example, the way that builders pick nails isn't by accounting for humidity levels or type of wood they use (older pressure-treated wood can corrode certain metals faster, same as newer wood can corrode others.) Instead, most of them just grab what they have, so when nails start failing after a few decades that's not their problem. Not like the architect said to use all galvanized nails everywhere. But I digress. Here is how bricklayers and programmers are similar: they commonly work in the vacuum of their own workspace, without awareness of the environment that impacts their projects. So once the projects are launched, they're impacted by things that weren't accounted for. If the foundation is too weak, the brick wall will sag. If nearby trees grow too close to the wall, the wall will bow inward or outward. If someone builds on top of the brick wall and doesn't reinforce it over 8 feet, the inspector will condemn the work. The bricklayers are paid to just lay bricks, so they won't care about the nearby trees, they won't care about the foundation, they won't care about what you put on top of the wall. Programmers will build the project to spec, and come launch time, not account for a particular load signature because that was never their concern. Seen that time and time again. Substitute foundation for baseline server power, trees for amount of interrupting processes and meddling managers altering the original program at random, and you have a pretty reasonable comparison to bricklaying.

marcus_holmes 12y ago
I'm sorry but if you employ programmers to build the project to spec without any awareness of the environment it's going to be deployed to, then no wonder you see that problem time and time again. The problem here is not that you have insufficiently detailed specs, but that you're treating your programmers like bricklayers. I strongly suggest you try bringing your programmers into the room during the specification process, even get them to write some prototype code to explore the tricky areas (something bricklayers don't get to do either). You'll probably find you get better code as a result because the people writing the code are aware of the environment the code will be deployed to.
- 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

I'm sorry but if you employ programmers to build the project to spec without any awareness of the environment it's going to be deployed to, then no wonder you see that problem time and time again. The problem here is not that you have insufficiently detailed specs, but that you're treating your programmers like bricklayers. I strongly suggest you try bringing your programmers into the room during the specification process, even get them to write some prototype code to explore the tricky areas (something bricklayers don't get to do either). You'll probably find you get better code as a result because the people writing the code are aware of the environment the code will be deployed to.

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.