4 ms·

The parent literally said it was a "shitty solution". I agree design by committee can produce awful results - and I said nothing about a single person doing a

by mugsie 7y ago

The parent literally said it was a "shitty solution". I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.

koheripbal 7y ago
People overestimate the duration that their software will be used, so in many cases imperfections aren't as important as a developer might think they are. My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.
- mugsie 7y ago
  > You may look good, but the team / dept / company is worse off, and someone else has to clean up. The people/team handling it manually probably care
  - eitland 7y ago
    Here’s a problem: The alternative to shipping something that works good enough, on time often isn’t to ship something perfect on time but to not ship on time or even worse, -at all. That would be even worse for the people/team supposed to use the product.
- tempguy9999 7y ago
  > People overestimate the duration that their software will be used Please justify that. I did some software, a not too complex chunk of work for a midlands (UK) retailer in 1999. It dealt with a couple of million pounds of retail orders that year. Not so big but not trivial either. It was still in use in 2015, and quite possibly is today (although the boss told me they re-used it for a rather different purpose by their sales reps). It was very reliable because I fought to keep it simple, and tested it brutally (eg. the core part took 5 days to write but got 3 weeks testing, founding only 2 errors, but it was 2 errors fewer). If it was crap it would have been junked so I'll claim that the end quality contributes to its life. High reliability tends to stick around. I think lex/yacc started in the 70s and is still around today in the form of its spiritual successors flex/bison. Ancient but still grinding along. ' In a 2008 interview, Johnson reflected that "the contribution Yacc made to the spread of Unix and C is what I'm proudest of" ' (https://en.wikipedia.org/wiki/Yacc https://en.wikipedia.org/wiki/Yacc) If you ship crap its lifetime is intrinsically much shortened. That's my thesis anyway.

by mugsie 7y ago

The parent literally said it was a "shitty solution". I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.

koheripbal 7y ago

People overestimate the duration that their software will be used, so in many cases imperfections aren't as important as a developer might think they are. My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.

mugsie 7y ago
> You may look good, but the team / dept / company is worse off, and someone else has to clean up. The people/team handling it manually probably care
- eitland 7y ago
  Here’s a problem: The alternative to shipping something that works good enough, on time often isn’t to ship something perfect on time but to not ship on time or even worse, -at all. That would be even worse for the people/team supposed to use the product.
tempguy9999 7y ago
> People overestimate the duration that their software will be used Please justify that. I did some software, a not too complex chunk of work for a midlands (UK) retailer in 1999. It dealt with a couple of million pounds of retail orders that year. Not so big but not trivial either. It was still in use in 2015, and quite possibly is today (although the boss told me they re-used it for a rather different purpose by their sales reps). It was very reliable because I fought to keep it simple, and tested it brutally (eg. the core part took 5 days to write but got 3 weeks testing, founding only 2 errors, but it was 2 errors fewer). If it was crap it would have been junked so I'll claim that the end quality contributes to its life. High reliability tends to stick around. I think lex/yacc started in the 70s and is still around today in the form of its spiritual successors flex/bison. Ancient but still grinding along. ' In a 2008 interview, Johnson reflected that "the contribution Yacc made to the spread of Unix and C is what I'm proudest of" ' (https://en.wikipedia.org/wiki/Yacc https://en.wikipedia.org/wiki/Yacc) If you ship crap its lifetime is intrinsically much shortened. That's my thesis anyway.