> Let me say it plainly: We know how to produce small portions of software using small development teams—up to 10 or so—but we don’t know how to make software a

> Let me say it plainly: We know how to produce small portions of software using small development teams—up to 10 or so—but we don’t know how to make software any larger except by accident or by rough trial and error.—Because the software we’re trying to build is too massive—it is simply too difficult to plan it all out, and we have no idea how to coordinate the number of people it takes. Every piece of software built requires tremendous attention to detail and endless fiddling to get right. I was faced with the same problem when I wrote my first program in assembler. I solved this by making blocks. At the begin and end of each block, I put the requirements and guarantees on the value in each register in a comment. I work as a IT consultant and maybe my vision is skewed, but I never encountered that very basic level of specification before. At the companies where I have worked, requirements are usually specified verbally, in a loose way. Additionally, OOP concepts are (ab)used, so you there is a lot more state to keep track of. I imagine that if you think about the structure of the project and specify interfaces of units very precisely (both in terms of what in- and output is allowed, what data types, etc.), this would work a lot better. In terms of structured working for myself, my background in math and low-level programming has helped me a lot. In terms of working in a team, it has made me aware of how little concrete information is written down, and how much information is in peoples heads only.