4 ms·

This attitude strikes me as very SV/HN and while I can appreciate certain elements here, the answer is the typical one - "It depends." Rather than regurgitate

This attitude strikes me as very SV/HN and while I can appreciate certain elements here, the answer is the typical one - "It depends." Rather than regurgitate what most people here already said, let me list a few programming projects, domains, and tasks where at least thinking about design if not writing design documents or spending days, weeks, or months figuring it all out is worthwhile. * Programming Languages * Databases * Operating Systems * Medical Devices * Safety Equipment * Streaming containers/formats * Encryption * Security * Manufacturing/Robotics * Aerospace / Space * App Dev Frameworks * Game Engines I could go on. The point here is that there are plenty of things where thinking about it up front is beneficial, if not required, especially if some combination (but not limited to) the following are true: * Lives are at stake * Changing it later would be hard (programming languages are an egregious offender, I won't name names) * Customer adoption will completely derail or forbid architectural changes * Fixing it will require essentially doing it again from scratch * Changes will force the creation of patches that will incrementally kill the project or slow future development Frankly, I think we have too many things that are poorly designed. Most projects I see in nearly any domain are mostly set in stone once time and money is added to the mix. Everyone talks about redoing or fixing things, but it rarely happens except for minor changes. As projects scale up, few people can afford to constantly back out lots of changes and rearchitect everything. Those that do usually fail or don't get a good ROI, and those that don't change fail anyway. I've worked with all kinds of people and though there are people I have great admiration for, I can safely say that 99% of them are idiots and have no business being programmers. I know it sounds harsh, but I've been doing this a long time and have worked with all kinds of people. Too often I see the programmer's equivalent of an illiterate child that gets pushed through high school. So no, I don't trust people to do the right thing, I merely trust most people I work with to not act maliciously. Most of all, I don't trust myself. As the progression goes as a programmer - your code sucks -> my code sucks -> all code sucks -> my code sucks but I'll live with it, hope it is better than most, and ask people smarter than me for help. Most better developers I know do in fact right some form of design documents, even if it's just notes and justification why X or Y won't work, but Z "might" work. Many also take a lot of time to think about something before writing any code, but once they do, they actually finish much quicker with less bugs than the young programmers who want to "move fast." Of course none of this is universal, and as I said, it all just "depends." What do I know?

fdsfsaa 10y ago
> 99% of them are idiots and have no business being programmers I feel the same way. If you have a group of idiots, you need process as a harm reduction measure. A very high contributor bar is a prerequisite for a process-light environment, because if you can't trust people to do the right thing, you need a system to force them into a conservative approximation of the right thing, and this system is called process.
- beat 10y ago
  So what you're proposing is that every company hire only the best? That's what they all think they're doing. Math doesn't work that way.
  - optionalparens 10y ago
    Not sure what you are replying to, but I think at least parent is saying because people aren't as good as they should be, you put processes in place. I don't think anyone is saying what you stated. Most companies might believe they are hiring the best, but their coworkers are the ones that know otherwise and do things like use design documents to give some structure where needed. In other words, you take measures to catch errors, mitigate failures, and protect yourself rather than say "go code and push to production everyone, we can just roll back!" That might work as stated in some domains, but not others.

fdsfsaa 10y ago

> 99% of them are idiots and have no business being programmers I feel the same way. If you have a group of idiots, you need process as a harm reduction measure. A very high contributor bar is a prerequisite for a process-light environment, because if you can't trust people to do the right thing, you need a system to force them into a conservative approximation of the right thing, and this system is called process.

beat 10y ago
So what you're proposing is that every company hire only the best? That's what they all think they're doing. Math doesn't work that way.
- optionalparens 10y ago
  Not sure what you are replying to, but I think at least parent is saying because people aren't as good as they should be, you put processes in place. I don't think anyone is saying what you stated. Most companies might believe they are hiring the best, but their coworkers are the ones that know otherwise and do things like use design documents to give some structure where needed. In other words, you take measures to catch errors, mitigate failures, and protect yourself rather than say "go code and push to production everyone, we can just roll back!" That might work as stated in some domains, but not others.