4 ms·
> Writing documentation up front is a good idea, but only if one treats it as the first iteration of the program with the expectation that the initial documenta
by 6510 2y ago
> Writing documentation up front is a good idea, but only if one treats it as the first iteration of the program with the expectation that the initial documentation may well be thrown out. The process of writing the documentation no doubt will help you organize the plan for writing the code. But there will also be things that the documentation does not capture or problems it does not foresee that emerge as the program is being written.
Everyone else is building all kinds of things from technical drawings. We could identify and describe what is so different about writing code which would make it clear what not to document or we can just suck it up, stop pretending our problems are special and closely mimic existing methods :)
Making a construction drawing is hard but people are some how doing it, they make them for mind blowing size projects. Things definitely go wrong but no one says it is just the way things are. If changes are made there shall be new drawings.
However, when it comes to renovation or repairs the process is often the opposite. Unless it is a boat, there if every brush of paint is meticulously documented it adds value in $$$.
A friend told a funny story about construction workers building a large building across the street while they were debugging their code. First he joked about construction workers doing real work, then about how structured everything was and eventually about the building being finished while they still had countless bugs.
- Swizec 2y ago> Things definitely go wrong but no one says it is just the way things are. If changes are made there shall be new drawings. > then about how structured everything was and eventually about the building being finished while they still had countless bugs There is a famous story of the Hyatt Walkway Collapse where a change was made, was improperly documented, and caused a production bug that led to many deaths. Extreme example but production bugs in physical construction are extremely common. https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse edit: Here's a whole paper looking into the effects of design errors in construction projects. This implies they're common enough to study. https://www.researchgate.net/publication/330701193_EFFECTS_OF_DESIGN_ERRORS_ON_CONSTRUCTION_PROJECTS https://www.researchgate.net/publication/330701193_EFFECTS_O... And here's some research that showed 10% to 25% of cost in construction goes towards fixing errors. https://getitright.uk.com/reports/call-to-action https://getitright.uk.com/reports/call-to-action
- 6510 2y agoConstruction has a much more mature building process, much of that is probably related to the cost of replacing things. We even get to cut and paste :) That last document seems like something that could be done in software development. Their list (starting with the worse) is dominated by mistakes pouring concrete. - Inadequate planning (from task through to project level) - Late design changes - Poorly communicated design information - Poor culture in relation to quality - Poorly coordinated and incorrect design information - Inadequate attention paid in the design to construction - Excessive commercial (financial and time) pressures - Poor interface management and design - Ineffective communication between team members - Inadequate supervisory skills For software we would have to gather the data similarly. Then you put it all into an LLM along with the employees previous assignments and code, pull the lever and the answers come out. Ah, yes. The aim should be to have pure information so that insurance companies can pick up the bill. In order to accomplish that the system should prevent the employer from meddling in the process. Working from home seems required to properly benchmark the employees.