4 ms·

I almost always write the major steps as comments (beginning with 'TODO:') first and then do the implementation once I'm satisfied that I know what a good solut

by skgoa 9y ago

I almost always write the major steps as comments (beginning with 'TODO:') first and then do the implementation once I'm satisfied that I know what a good solution looks like. Over the years I have had the misfortune to discover way too many functions that just were 50% implemented or simply did something that was not at all what they were supposed to do. I don't doubt that conscientious developers can arrive at good code however they prefer. But there are a lot of people out there who will start with a quick and dirty implementation that they then debug into a more or less functional state. I see a push towards making people stop and take a moment to think about what they are going to do. Test-driven development is another tool to achieve that end.

shubb 9y ago
That's more like the carpenter drawing marks in the wood to tell him where to cut. I feel like, complexity is a problem when there is more software than one person could write. At this point, you probably need to do some Business Analyst type stuff. For instance, we are aware of race conditions in code, and maybe we can avoid them by writing purely functional programmes in rust or whatever people do these days. But what about the race condition of several servers restarting repeatedly and coming back up in a different order? Or a customer registering online when he already sent a form in by post? The oldschool way of doing this was big UML drawings. This was a compromise because both programmers and business subject matter experts hate drawing them equally. People don't tend to do this anymore because it is 90s and smells of XML and Java. But what replaced it?
- burntsushi 9y ago
  Note that Rust doesn't prevent race conditions. Race conditions are application specific. Rust prevents data races, which has a very specific technical definition: an unsynchronized read and write to the same location in memory.

by skgoa 9y ago

shubb 9y ago

That's more like the carpenter drawing marks in the wood to tell him where to cut. I feel like, complexity is a problem when there is more software than one person could write. At this point, you probably need to do some Business Analyst type stuff. For instance, we are aware of race conditions in code, and maybe we can avoid them by writing purely functional programmes in rust or whatever people do these days. But what about the race condition of several servers restarting repeatedly and coming back up in a different order? Or a customer registering online when he already sent a form in by post? The oldschool way of doing this was big UML drawings. This was a compromise because both programmers and business subject matter experts hate drawing them equally. People don't tend to do this anymore because it is 90s and smells of XML and Java. But what replaced it?

burntsushi 9y ago
Note that Rust doesn't prevent race conditions. Race conditions are application specific. Rust prevents data races, which has a very specific technical definition: an unsynchronized read and write to the same location in memory.