3 ms·

But the article directly says source code can't be the spec because it contains low level details. E.g. you implement something with map/apply instead of loops

by erikb 12y ago

But the article directly says source code can't be the spec because it contains low level details. E.g. you implement something with map/apply instead of loops because that's all your programming language has, or your filter out some characters from a data stream because they often make a third party parser raise Exceptions you don't understand. These are programming details that the source code contains but the spec shouldn't. Therefore I think your argument is debunked by the main article already. In any case it's a good discussion to have in this thread, which is why I gave you the up.

marcus_holmes 12y ago
An Architect's drawing of a building contains every single detail of that house. It's not a high-level sketch of what needs to be built, it's an exhaustive plan for every part of the finished product that has been extensively iterated with the customer to make sure it's correct. Changes to this plan once complete are expensive. So yes, it's exactly like code. But I just wish people would stop comparing software development to construction. They're not alike at all, not even vaguely. Programming is not like bricklaying, because bricklaying is deterministic and uncreative: there is one correct method of laying the bricks, and any two competent bricklayers will lay the bricks in exactly the same way. But there is never one single correct method of writing a program, and no two programmers will implement a feature in the same way. Any attempt to create a specification so exhausting that it allows no deviation by individual programmers should stop pretending it's a spec and just write the damn code. In fact, the author of the article should probably stop writing specs and just iterate prototypes to achieve the same end: there's no difference between "understanding our programming task" in formal English or understanding it in code, except that the code is more useful and a lot easier to test.
- erikb 12y ago
  There are many points worth of discussion in your comment. I just pick one for now. The details of the architects work. I am no architect, so all I think about it can be true or false. But what I remember from an architect friend is that an architect's work is not really that detailed. It's like the photoshop mockup of a website, not like its source code. It doesn't say exactly which materials should be chosen or how many screws should be used to connect two ends. An architects design says "There is a wall x cm thick and y cm long". The source code says "There z bricks and the last one we had to cut to n cm" (sometimes a comment will state why it had to be cut). For the source code it is to some degree by accident the amount of bricks creates something that can be called a wall.
  - cam_l 12y ago
    Well, my work is pretty detailed! But all the information about the correct numbers of bricks, the slump of the mortar, the number and type of screws - these are all just library functions. Why would you re-write all that perfectly serviceable code for each project?
    - erikb 12y ago
      Getting a library to work for your use case is exactly one of those things that needs quite a few workaround which the bricks are not part of the library. The library is the earth you build your bricks on top and you need to put in some work that your bricks can stand on it.
- 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

by erikb 12y ago

marcus_holmes 12y ago

An Architect's drawing of a building contains every single detail of that house. It's not a high-level sketch of what needs to be built, it's an exhaustive plan for every part of the finished product that has been extensively iterated with the customer to make sure it's correct. Changes to this plan once complete are expensive. So yes, it's exactly like code. But I just wish people would stop comparing software development to construction. They're not alike at all, not even vaguely. Programming is not like bricklaying, because bricklaying is deterministic and uncreative: there is one correct method of laying the bricks, and any two competent bricklayers will lay the bricks in exactly the same way. But there is never one single correct method of writing a program, and no two programmers will implement a feature in the same way. Any attempt to create a specification so exhausting that it allows no deviation by individual programmers should stop pretending it's a spec and just write the damn code. In fact, the author of the article should probably stop writing specs and just iterate prototypes to achieve the same end: there's no difference between "understanding our programming task" in formal English or understanding it in code, except that the code is more useful and a lot easier to test.

erikb 12y ago
There are many points worth of discussion in your comment. I just pick one for now. The details of the architects work. I am no architect, so all I think about it can be true or false. But what I remember from an architect friend is that an architect's work is not really that detailed. It's like the photoshop mockup of a website, not like its source code. It doesn't say exactly which materials should be chosen or how many screws should be used to connect two ends. An architects design says "There is a wall x cm thick and y cm long". The source code says "There z bricks and the last one we had to cut to n cm" (sometimes a comment will state why it had to be cut). For the source code it is to some degree by accident the amount of bricks creates something that can be called a wall.
- cam_l 12y ago
  Well, my work is pretty detailed! But all the information about the correct numbers of bricks, the slump of the mortar, the number and type of screws - these are all just library functions. Why would you re-write all that perfectly serviceable code for each project?
  - erikb 12y ago
    Getting a library to work for your use case is exactly one of those things that needs quite a few workaround which the bricks are not part of the library. The library is the earth you build your bricks on top and you need to put in some work that your bricks can stand on it.
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