4 ms·

> Not deterred, I hacked into it a shitty solution and shipped it very fast. And moved the burden of maintenance to someone else? If so, this is one of the thi

by mugsie 7y ago

> Not deterred, I hacked into it a shitty solution and shipped it very fast. And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.

deleted 7y ago
[deleted]
jacquesm 7y ago
Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better because they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.
- 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.
- fogetti 7y ago
  So tell us, how is a shitty solution better than a well designed testable solution? Literally every book on project management is about the development cost vs maintenance cost and how the latter beats the former. But yeah, keep dreaming.
  - supermatt 7y ago
    Because what a "10x developer" (i would just call them pragmatic, personally) might call a shitty solution is still better than what you may call a well designed testable solution? Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.
    - mamon 7y ago
      This is so true, because people that are really good at something usually hold themselves to incredibly high standards (which is one of the main reasons they become master craftsmen in the first place).
      - fogetti 7y ago
        Yes. The standard is so high that they can't even find words for it. So they just call it simply shitty.
        deleted 7y ago
        [deleted]
    - mugsie 7y ago
      Not at all. The quality of the code may be terrible. BUT - when someone else new comes along to look at it, the 90% code coverage, and comments helps them immensely - they can get up to speed to fix whatever bug has appeared a lot quicker.
    - fogetti 7y ago
      Pragmatism based on shittyism? Or how shall we imagine this? Is there a motto for this? "We excel in shitty code or something?"
deleted 7y ago
[deleted]
gvb 7y ago
Keep reading... One day, I said "this needs to go", and everybody listened, architects and directors alike. By shipping something that worked he bought himself time and credibility which he then used to replace the shitty solution with good code.
- mugsie 7y ago
  No, they did a thing that got him ahead - and they hoped enough to fix the thing he did before. Now, if they hadn't gotten the credibility (due to the short term fix for thing they wrote broke sooner than expected), or they gained a lot more credibility and moved in the company, or out of it, the broken thing would still be there, and someone would have inherited it, and had to refactor / relearn / replace it. One of the points about 10x devs that people are pushing back on is this - do the thing to a minimum spec, drop it on the floor, and get kudos for it, while the rest of the devs run around picking up the pieces.
tasuki 7y ago
> And moved the burden of maintenance to someone else? If you read on: > > One day, I said "this needs to go", and everybody listened, architects and directors alike. The OP hacked a shitty solution to make people listen to him. Once people started listening to him, he found it easier to persuade them to let him improve things.
geezerjay 7y ago
> And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. Sometimes the burden of maintenance is the price you have to pay go get an operational/production system early on and enables you to let other requirements emerge earlier. You might focus on the "burden of maintenance", and also assume that you're saving time by taking the long route to production, but letting requirements emerge early on in the project is also a significant time saver as it enables the project to avoid committing the mistake of investing time developing a goldplated solution that will have to be thrown out. You need to accept the fact that the "burden of maintenance" is always there and it will always be there, whether you invest years rolling your goldplated solution or just dash to production with a quick and dirty solution. You don't get rid of that burden by aiming for an academically pristine implementation that takes ages to deliver. Requirements do change, and do so continuously. Heck, designing stuff for a scale that will never be required is also a major problem. So, why would anyone be concerned with having to spend 120% of the time developing a solution if that path enables you to get up and running in 20% of the time?

by mugsie 7y ago

deleted 7y ago

[deleted]

jacquesm 7y ago

Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better because they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.

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.
fogetti 7y ago
So tell us, how is a shitty solution better than a well designed testable solution? Literally every book on project management is about the development cost vs maintenance cost and how the latter beats the former. But yeah, keep dreaming.
- supermatt 7y ago
  Because what a "10x developer" (i would just call them pragmatic, personally) might call a shitty solution is still better than what you may call a well designed testable solution? Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.
  - mamon 7y ago
    This is so true, because people that are really good at something usually hold themselves to incredibly high standards (which is one of the main reasons they become master craftsmen in the first place).
    - fogetti 7y ago
      Yes. The standard is so high that they can't even find words for it. So they just call it simply shitty.
      - deleted 7y ago
        [deleted]
  - mugsie 7y ago
    Not at all. The quality of the code may be terrible. BUT - when someone else new comes along to look at it, the 90% code coverage, and comments helps them immensely - they can get up to speed to fix whatever bug has appeared a lot quicker.
  - fogetti 7y ago
    Pragmatism based on shittyism? Or how shall we imagine this? Is there a motto for this? "We excel in shitty code or something?"

deleted 7y ago

[deleted]

gvb 7y ago

Keep reading... One day, I said "this needs to go", and everybody listened, architects and directors alike. By shipping something that worked he bought himself time and credibility which he then used to replace the shitty solution with good code.

mugsie 7y ago
No, they did a thing that got him ahead - and they hoped enough to fix the thing he did before. Now, if they hadn't gotten the credibility (due to the short term fix for thing they wrote broke sooner than expected), or they gained a lot more credibility and moved in the company, or out of it, the broken thing would still be there, and someone would have inherited it, and had to refactor / relearn / replace it. One of the points about 10x devs that people are pushing back on is this - do the thing to a minimum spec, drop it on the floor, and get kudos for it, while the rest of the devs run around picking up the pieces.

tasuki 7y ago

> And moved the burden of maintenance to someone else? If you read on: > > One day, I said "this needs to go", and everybody listened, architects and directors alike. The OP hacked a shitty solution to make people listen to him. Once people started listening to him, he found it easier to persuade them to let him improve things.

geezerjay 7y ago

> And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. Sometimes the burden of maintenance is the price you have to pay go get an operational/production system early on and enables you to let other requirements emerge earlier. You might focus on the "burden of maintenance", and also assume that you're saving time by taking the long route to production, but letting requirements emerge early on in the project is also a significant time saver as it enables the project to avoid committing the mistake of investing time developing a goldplated solution that will have to be thrown out. You need to accept the fact that the "burden of maintenance" is always there and it will always be there, whether you invest years rolling your goldplated solution or just dash to production with a quick and dirty solution. You don't get rid of that burden by aiming for an academically pristine implementation that takes ages to deliver. Requirements do change, and do so continuously. Heck, designing stuff for a scale that will never be required is also a major problem. So, why would anyone be concerned with having to spend 120% of the time developing a solution if that path enables you to get up and running in 20% of the time?