5 ms·

It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short

by cle 7y ago

It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.

ivanhoe 7y ago
Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.
- deleted 7y ago
  [deleted]
- Godel_unicode 7y ago
  s/know/think See also yagni, premature optimization, etc, etc
  - emodendroket 7y ago
    Yeah those are all useful rules of thumb but I doubt anybody is gonna tell you that the point of those is that you should just not give a damn about anything besides whether your code can tick off the AC of a ticket.
    - Godel_unicode 7y ago
      My point is that a lot of engineers freak out about things they read a Facebook engineering blog post about, and are "engineering" a crazy complex system for months to handle non-facebook volumes of traffic. They then reassure themselves by valuing the ideological purity of their design over the months salary they wasted on building their Sistine chapel of REST. This is mid-level engineers all day, every day.
      - emodendroket 7y ago
        Yes, sure, that sucks, but you need some kind of balance, because sometimes you dig a hole that's so deep it's hard to get out of. Surely part of being "senior" is having some sense of what kind of abstractions and optimizations are worth making up-front and which can be saved for when they become necessary.
    - cle 7y ago
      That's not at all what I said. Engineering discipline is important.
rootusrootus 7y ago
This deserves more upvotes. I have met so many engineers who do themselves a disservice by overvaluing the esoteric bits of code that nobody but their team will ever see. The business doesn't care as long as it works, and soon. Which isn't to say that you shouldn't sometimes sweat the small stuff, but you always have to remember that you're working for a business.
theamk 7y ago
Only if you don't care about long-term. Those things are not "platitudes", those are lessons learned from the experience keeping large systems maintainable. (that said, there are plenty of systems where long-term term does not really matter, as well as cases when good rules are taken to absurd levels)
aero142 7y ago
You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I've personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.
- JamesBarney 7y ago
  Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues. I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.
  - hinkley 7y ago
    My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there. Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite). I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?). Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do. In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog. Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.
hinkley 7y ago
We discount logistics a lot when we have conversations like this. One speaker years back (possibly before Scrum darkened our doors) disagreed with the Tech Debt analogy and asserted that we're talking about wear and tear. At the end of the day, making a change that doesn't cause any strong feelings is much cheaper than one that does. A lot of these supposedly aesthetic, nitpicking conversations are about not feeling a sense of dread when you have to look at a piece of code. I want to say that 'dread is the precursor to procrastination," but I think there are some psychologists who want to claim that procrastination is dread. If you've ever seen anyone argue vehemently about how they can't do two 4 hour tasks in a day, it's probably because they know that one of those tasks is going to wipe them out and they'll spend the rest of the day recuperating, doing menial work or even goofing off. If I get to control the narrative for a project, which isn't often, then eventually I will remember the roads that have always worked for my teams. That projects go better when we feel like we're incrementally getting more productive all the time, instead of slowly calcifying. That our tools require progressively less vigilance, our code becomes less scary and we become less afraid of it. We talk about what we can productively accomplish instead of what's theoretically possible to pull off. We leverage that to throw in cheap features people didn't even know they wanted, or solve problems they did not know they have (twenty minutes watching a user is more informative than days of interviews and a mountain of surveys). That last bit may be more important than even I realize. How proud can you be of something you were ordered to do by someone you don't even interact with every day? I've never really thought of it that way before but I sure am now...
emodendroket 7y ago
Yes, but what if your failure on those other fronts start to compromise the timely delivery of correct software that performs acceptably?
dragonwriter 7y ago
> You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built. Short functions and DRY are a near universal component of fast delivery, but they are part of the set of practices that mostly enables faster delivery in the increments after the one they are applied in (though I've certainly had single sprints where my delivery time was better because I implemented a reusable abstraction early one that was used repeatedly in that task) so people focussed on fast delivery (as almost all are) who lack more than a myopic perspective tend to overlook them which has a compounding effect. So, yes, your long lost of things (of which they are a part) matters more together than they do alone, though I'd say that your list is broad platitudes that almost no one forgets are necessary in the abstract, but where concrete details of the last—including fairly context-independent ones like DRY and short functions, as well as more context-dependent ones—frequently do get overlooked, especially when the return is not mainly immediate.

by cle 7y ago

ivanhoe 7y ago

Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.

deleted 7y ago
[deleted]
Godel_unicode 7y ago
s/know/think See also yagni, premature optimization, etc, etc
- emodendroket 7y ago
  Yeah those are all useful rules of thumb but I doubt anybody is gonna tell you that the point of those is that you should just not give a damn about anything besides whether your code can tick off the AC of a ticket.
  - Godel_unicode 7y ago
    My point is that a lot of engineers freak out about things they read a Facebook engineering blog post about, and are "engineering" a crazy complex system for months to handle non-facebook volumes of traffic. They then reassure themselves by valuing the ideological purity of their design over the months salary they wasted on building their Sistine chapel of REST. This is mid-level engineers all day, every day.
    - emodendroket 7y ago
      Yes, sure, that sucks, but you need some kind of balance, because sometimes you dig a hole that's so deep it's hard to get out of. Surely part of being "senior" is having some sense of what kind of abstractions and optimizations are worth making up-front and which can be saved for when they become necessary.
  - cle 7y ago
    That's not at all what I said. Engineering discipline is important.

rootusrootus 7y ago

This deserves more upvotes. I have met so many engineers who do themselves a disservice by overvaluing the esoteric bits of code that nobody but their team will ever see. The business doesn't care as long as it works, and soon. Which isn't to say that you shouldn't sometimes sweat the small stuff, but you always have to remember that you're working for a business.

theamk 7y ago

Only if you don't care about long-term. Those things are not "platitudes", those are lessons learned from the experience keeping large systems maintainable. (that said, there are plenty of systems where long-term term does not really matter, as well as cases when good rules are taken to absurd levels)

aero142 7y ago

You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I've personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.

JamesBarney 7y ago
Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues. I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.
- hinkley 7y ago
  My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there. Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite). I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?). Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do. In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog. Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.

hinkley 7y ago

We discount logistics a lot when we have conversations like this. One speaker years back (possibly before Scrum darkened our doors) disagreed with the Tech Debt analogy and asserted that we're talking about wear and tear. At the end of the day, making a change that doesn't cause any strong feelings is much cheaper than one that does. A lot of these supposedly aesthetic, nitpicking conversations are about not feeling a sense of dread when you have to look at a piece of code. I want to say that 'dread is the precursor to procrastination," but I think there are some psychologists who want to claim that procrastination is dread. If you've ever seen anyone argue vehemently about how they can't do two 4 hour tasks in a day, it's probably because they know that one of those tasks is going to wipe them out and they'll spend the rest of the day recuperating, doing menial work or even goofing off. If I get to control the narrative for a project, which isn't often, then eventually I will remember the roads that have always worked for my teams. That projects go better when we feel like we're incrementally getting more productive all the time, instead of slowly calcifying. That our tools require progressively less vigilance, our code becomes less scary and we become less afraid of it. We talk about what we can productively accomplish instead of what's theoretically possible to pull off. We leverage that to throw in cheap features people didn't even know they wanted, or solve problems they did not know they have (twenty minutes watching a user is more informative than days of interviews and a mountain of surveys). That last bit may be more important than even I realize. How proud can you be of something you were ordered to do by someone you don't even interact with every day? I've never really thought of it that way before but I sure am now...

emodendroket 7y ago

Yes, but what if your failure on those other fronts start to compromise the timely delivery of correct software that performs acceptably?

dragonwriter 7y ago

> You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built. Short functions and DRY are a near universal component of fast delivery, but they are part of the set of practices that mostly enables faster delivery in the increments after the one they are applied in (though I've certainly had single sprints where my delivery time was better because I implemented a reusable abstraction early one that was used repeatedly in that task) so people focussed on fast delivery (as almost all are) who lack more than a myopic perspective tend to overlook them which has a compounding effect. So, yes, your long lost of things (of which they are a part) matters more together than they do alone, though I'd say that your list is broad platitudes that almost no one forgets are necessary in the abstract, but where concrete details of the last—including fairly context-independent ones like DRY and short functions, as well as more context-dependent ones—frequently do get overlooked, especially when the return is not mainly immediate.